<?xml version="1.0" encoding="utf-8"?>
<feed version="0.3" xmlns="http://purl.org/atom/ns#" xmlns:dc="http://purl.org/dc/elements/1.1/" xml:lang="en">
<title>Kelly O&apos;Hair&apos;s Blog</title>
<link rel="alternate" type="text/html" href="http://weblogs.java.net/blog/kellyohair/" />
<modified>2008-02-13T18:05:20Z</modified>
<tagline></tagline>
<id>tag:weblogs.java.net,2008:/blog/kellyohair/244</id>
<generator url="http://www.movabletype.org/" version="3.01D">Movable Type</generator>
<copyright>Copyright (c) 2008, kellyohair</copyright>
<entry>
<title>Two Blogs Too Many</title>
<link rel="alternate" type="text/html" href="http://weblogs.java.net/blog/kellyohair/archive/2008/01/two_blogs_too_m.html" />
<modified>2008-02-13T18:05:20Z</modified>
<issued>2008-01-08T01:41:21Z</issued>
<id>tag:weblogs.java.net,2008:/blog/kellyohair/244.8940</id>
<created>2008-01-08T01:41:21Z</created>
<summary type="text/plain"> Just FYI... Maintaining two blog sites is a bit problematic, I&apos;ll be doing most future Java blogs on blogs.sun.com: http://blogs.sun.com/kto/category/Java -kto...</summary>
<author>
<name>kellyohair</name>

<email>Kelly.Ohair@Sun.COM</email>
</author>
<dc:subject>Community: JDK</dc:subject>
<content type="text/html" mode="escaped" xml:lang="en" xml:base="http://weblogs.java.net/blog/kellyohair/">
<![CDATA[<p>
Just FYI...

<p>
Maintaining two blog sites is a bit problematic, I'll be doing most future Java blogs on blogs.sun.com:
<a href="http://blogs.sun.com/kto/category/Java">
http://blogs.sun.com/kto/category/Java</a>

<p>
-kto]]>

</content>
</entry>
<entry>
<title>OpenJDK Mercurial Transition Final Update</title>
<link rel="alternate" type="text/html" href="http://weblogs.java.net/blog/kellyohair/archive/2007/12/openjdk_mercuri_7.html" />
<modified>2008-02-13T18:05:20Z</modified>
<issued>2007-12-05T16:15:55Z</issued>
<id>tag:weblogs.java.net,2007:/blog/kellyohair/244.8757</id>
<created>2007-12-05T16:15:55Z</created>
<summary type="text/plain"> Final Update Hip Hip Hooray! JDK7 Build 24 has been promoted (no raise, just a promotion :^). Remember, Build 24 should not differ from Build 23, in fact if they don&apos;t behave exactly the same, please report it as...</summary>
<author>
<name>kellyohair</name>

<email>Kelly.Ohair@Sun.COM</email>
</author>
<dc:subject>Community: JDK</dc:subject>
<content type="text/html" mode="escaped" xml:lang="en" xml:base="http://weblogs.java.net/blog/kellyohair/">
<![CDATA[<html>
<body>

<h2> Final Update </h2>

<ul>

<h1>Hip Hip Hooray!</h1>

<p>
JDK7 Build 24 has been promoted (no raise, just a promotion :^).
Remember, Build 24 should not differ from Build 23, in fact if they don't behave exactly the same, please report it as a bug.
The only difference is that Build 23 was built from sources that lived
in TeamWare workspaces, and Build 24 was built from those same sources living in Mercurial repositories.

<p>
The open source repositories used to create Build 24 are available at:
<a href="http://hg.openjdk.java.net/jdk7/jdk7/"><b>http://hg.openjdk.java.net/jdk7/jdk7/</b></a>.
These are often called the jdk7 master repositories.

<p>
If you have Mercurial installed on your system, and you have it setup with the forest extension on, building the openjdk should be as easy as:<tt><pre><b><ul>
hg fclone http://hg.openjdk.java.net/jdk7/jdk7 yourjdk7
cd yourjdk7
<a href="http://www.gnu.org/software/make/">make</a>
./build/*/j2sdk-image/bin/java -version
</ul></b></pre></tt>

<p>
"Ha!" he says, like it can be so easy. :^) <br>
Refer to the complete build instructions in the file <tt>yourjdk7/README-builds.html</tt>.
Hopefully, over the next few months, I can now fix some of the build problems people have been running into.
I'll push my build changes into the build area at
<a href="http://hg.openjdk.java.net/jdk7/build">http://hg.openjdk.java.net/jdk7/build</a>
along with anyone else making build related changes, and then occasionally this build area will be integrated into the master repositories.
The same integration procedure that many of the team areas will follow, although it may take some time for all the various pipelines
to warm up, so to speak.
Should be a fun ride, buckle your seat belts.

<p>
Speaking of fun rides, on Highway 101 in the Oregon Dunes area,
you can ride in a sand rail (with a professional driver),
definitely an <a href="http://en.wikipedia.org/wiki/E_ticket">"E Ticket"</a> ride.
<br>
<img alt="Rail.png" src="http://weblogs.java.net/blog/kellyohair/archive/Rail.png" width="512" />
<p>
Google "sanddunes frontier" for more information, no cloning necessary. ;^)

</ul>

<p>
-kto

</body>
</html>

]]>

</content>
</entry>
<entry>
<title>OpenJDK Mercurial Transition Update 7</title>
<link rel="alternate" type="text/html" href="http://weblogs.java.net/blog/kellyohair/archive/2007/11/openjdk_mercuri_1.html" />
<modified>2008-02-13T18:05:20Z</modified>
<issued>2007-11-15T22:01:50Z</issued>
<id>tag:weblogs.java.net,2007:/blog/kellyohair/244.8663</id>
<created>2007-11-15T22:01:50Z</created>
<summary type="text/plain"> Update 7 Ok ok, call us snails if you want... but things are progressing, really. We are currently going through a &quot;dry run&quot; event of having team integrators and developers learn Mercurial, clone the experimental repositories, push fake changes,...</summary>
<author>
<name>kellyohair</name>

<email>Kelly.Ohair@Sun.COM</email>
</author>
<dc:subject>Community: JDK</dc:subject>
<content type="text/html" mode="escaped" xml:lang="en" xml:base="http://weblogs.java.net/blog/kellyohair/">
<![CDATA[<html>
<body>

<h2> Update 7 </h2>

<ul>

<p>
Ok ok, call us snails if you want... but things are progressing, really.
We are currently going through a "dry run" event of having team
integrators and developers learn Mercurial, clone the experimental repositories,
push fake changes, and verify that the repositories work and the servers are stable. If you are on the build-dev@openjdk.java.net alias you may have seen the emails when the push events happened.
So far so good, we haven't gone running back to TeamWare, yet, (that's a joke :^).
Once Build 24 promotes and the
repositories are declared official we can all get back to real work
on the jdk.

<p>
So when will Build 24 promote? The Thanksgiving week created a bit of a problem, we came up with an unofficial perhaps slightly aggressive target of last week in November. So it's possible this slips into the first week of December, but we'll try and keep it in November.
Remember we have literally hundreds of Sun JDK developers involved with this transition, this is not a minor event.

<p>
The experimental repositories are still available at:
<a href="http://hg.openjdk.java.net"><b>http://hg.openjdk.java.net</b></a>.
And I encourage anyone considering working with these repositories
to try them out.

<p>
I know I said it before, but we are in the final lap, just keep stopping along the way to clean up the track... the "official" repositories should be available around the end of November.

</ul>

<p>
-kto

</body>
</html>

]]>

</content>
</entry>
<entry>
<title>OpenJDK Mercurial Transition Update 6</title>
<link rel="alternate" type="text/html" href="http://weblogs.java.net/blog/kellyohair/archive/2007/11/openjdk_mercuri_6.html" />
<modified>2008-02-13T18:05:20Z</modified>
<issued>2007-11-02T02:19:17Z</issued>
<id>tag:weblogs.java.net,2007:/blog/kellyohair/244.8546</id>
<created>2007-11-02T02:19:17Z</created>
<summary type="text/plain"> Update 6 Build 23 has been promoted, so far there is at least one build bug found (see 6624808 or this openjdk build-dev email). But these sources will be used pretty much &apos;as is&apos; to start the Mercurial repositories...</summary>
<author>
<name>kellyohair</name>

<email>Kelly.Ohair@Sun.COM</email>
</author>
<dc:subject>Community: JDK</dc:subject>
<content type="text/html" mode="escaped" xml:lang="en" xml:base="http://weblogs.java.net/blog/kellyohair/">
<![CDATA[<html>
<body>

<h2> Update 6 </h2>

<ul>

<p>
Build 23 has been promoted, so far there is at least one build bug found (see 
<a href="http://bugs.sun.com/view_bug.do?bug_id=6624808">6624808</a> or <a href="http://mail.openjdk.java.net/pipermail/build-dev/2007-October/000346.html">this openjdk build-dev email</a>).
But these sources will be used pretty much 'as is' to start the Mercurial repositories and Build 24,
of which experimental repositories are available at:
<a href="http://hg.openjdk.java.net"><b>http://hg.openjdk.java.net</b></a>
right now.
The control directory disappears and it's Makefile is made part of the
enclosing repository.
If you have the Mercurial forest extension in your Mercurial installation, you can simply:
<ul><tt>hg fclone  http://hg.openjdk.java.net/jdk7/MASTER</tt></ul>
<br>
And have your own forest clone of the OpenJDK to play with.
 
<p>
Also see
<a href="http://blogs.sun.com/kto/entry/openjdk_mercurial_forest">
OpenJDK forest</a>,
<a href="http://blogs.sun.com/kto/entry/openjdk_mercurial_wheel">
OpenJDK Integration Wheel</a>, and
<a href="http://blogs.sun.com/kto/entry/working_in_a_mercurial_world">
Working in a Mercurial World</a>
for more information.

<p>
We are in the final lap... "official" repositories are very close.

</ul>

<p>
-kto

</body>
</html>

]]>

</content>
</entry>
<entry>
<title>OpenJDK Mercurial Transition Update 5</title>
<link rel="alternate" type="text/html" href="http://weblogs.java.net/blog/kellyohair/archive/2007/10/openjdk_mercuri_5.html" />
<modified>2008-02-13T18:05:20Z</modified>
<issued>2007-10-21T21:10:59Z</issued>
<id>tag:weblogs.java.net,2007:/blog/kellyohair/244.8466</id>
<created>2007-10-21T21:10:59Z</created>
<summary type="text/plain"> Update 5 Well we had a few snafus with Build 22. A hotspot bug 6616627 managed to sneak in, and the jaxws workspace lost some GPL markings and we will need to back out the jaxws integration in Build...</summary>
<author>
<name>kellyohair</name>

<email>Kelly.Ohair@Sun.COM</email>
</author>
<dc:subject>Community: JDK</dc:subject>
<content type="text/html" mode="escaped" xml:lang="en" xml:base="http://weblogs.java.net/blog/kellyohair/">
<![CDATA[<html>
<body>

<h2> Update 5 </h2>

<ul>

<p>
Well we had a few snafus with Build 22.
A hotspot bug 
<a href="http://bugs.sun.com/view_bug.do?bug_id=6616627">6616627</a>
managed to sneak in, and the jaxws workspace lost some GPL markings
and we will need to back out the jaxws integration in Build 23
(this should be temporary, expect jaxws to be re-integrated in a few
builds).
<p>
The split of the langtools, corba, jaxp, and jaxws workspaces has
continued to cause some minor issues with regards to doing partial
builds from the j2se workspace. Most of these have been resolved
in build 23 coming up.

<p>
We did have a few changes to the plan.
Build 23 is being used (in TeamWare) to hold changes like
whitespace normalization, SCCS keyword removal, and
also the j2se name change ("j2se" is being changed to "jdk").
No team integrations will be allowed in Build 23 with the exception of
emergency fixes (like the above hotspot bug fix).

<p>
Build 24 will be in Mercurial and the files managed by TeamWare
in Build 23 will be the same files that enter the initial
Build 24 Mercurial repositories.
There are a few restructuring things that will happen though as
the Mercurial images are created. There will not be a "control"
repository, instead there will be a Makefile at the top of
the forest which is the same Makefile that used to be at
control/make.
So when you used to: 
<br>
<ul><tt>cd control/make &amp;&amp; gnumake</tt></ul>
<br> Now you would: 
<br>
<ul><tt>gnumake</tt></ul>

<p>
See
<a href="http://blogs.sun.com/kto/entry/openjdk_mercurial_forest">
OpenJDK forest</a> for more information on the layout.

<p>
Build 23 is being worked on now and should be available within
a week, doing the Mercurial conversion for Build 24 should be fairly
straight forward, but getting everything all setup for the
integrators and developers is not a trivial task, so once we
have repositories it may take a few weeks to get it all setup.
Hopefully, read-only MASTER repositories can be made available as
soon as possible, and maybe sooner so that we can get help trying
things out and looking for issues.

<p>
Stay tuned...

</ul>

<p>
-kto

</body>
</html>

]]>

</content>
</entry>
<entry>
<title>VisualVM Tool</title>
<link rel="alternate" type="text/html" href="http://weblogs.java.net/blog/kellyohair/archive/2007/10/visualvm_tool.html" />
<modified>2008-02-13T18:05:20Z</modified>
<issued>2007-10-17T19:22:23Z</issued>
<id>tag:weblogs.java.net,2007:/blog/kellyohair/244.8444</id>
<created>2007-10-17T19:22:23Z</created>
<summary type="text/plain"> If you like jconsole, go to the VisualVM pages at https://visualvm.dev.java.net/ and try out the new VisualVM tool. Very cool. -kto...</summary>
<author>
<name>kellyohair</name>

<email>Kelly.Ohair@Sun.COM</email>
</author>
<dc:subject>Community: JDK</dc:subject>
<content type="text/html" mode="escaped" xml:lang="en" xml:base="http://weblogs.java.net/blog/kellyohair/">
<![CDATA[<p>
If you like jconsole, go to the VisualVM pages at 
<a href="https://visualvm.dev.java.net/">
https://visualvm.dev.java.net/</a> and try out the new VisualVM tool.

<p>
Very cool.

<p>
-kto
]]>

</content>
</entry>
<entry>
<title>OpenJDK Mercurial Transition Update 4</title>
<link rel="alternate" type="text/html" href="http://weblogs.java.net/blog/kellyohair/archive/2007/10/openjdk_mercuri_4.html" />
<modified>2008-02-13T18:05:20Z</modified>
<issued>2007-10-02T19:57:24Z</issued>
<id>tag:weblogs.java.net,2007:/blog/kellyohair/244.8356</id>
<created>2007-10-02T19:57:24Z</created>
<summary type="text/plain"> Update 4 We tried very hard to split out corba, jaxp, and jaxws in Build 21 but didn&apos;t make it, however they just now got integrated into Build 22. This splits out an additional 6,000 files or so from...</summary>
<author>
<name>kellyohair</name>

<email>Kelly.Ohair@Sun.COM</email>
</author>
<dc:subject>Community: JDK</dc:subject>
<content type="text/html" mode="escaped" xml:lang="en" xml:base="http://weblogs.java.net/blog/kellyohair/">
<![CDATA[<html>
<body>

<h2> Update 4 </h2>

<ul>

<p>
We tried very hard to split out corba, jaxp, and jaxws in Build 21
but didn't make it, however they just now got integrated
into Build 22.
This splits out an additional 6,000 files or so from the primary j2se
workspace.
This would not have been accomplished at all without
the dedicated hard work of
<a href="http://www.linkedin.com/pub/0/694/46a">Seema</a>,
thank you Seema.

<p>
So with Build 22 we will now have:

<ul>
<li>
<b>control</b><br>
Primary control build make files.
Builds a complete or partial set of the components listed below.
</li>
<li>
<b>langtools</b><br>
Independently buildable javac, javah, javap, javadoc, and apt sources.
Uses a Makefile over an ant build script.
Contains NetBeans projects and tests.
</li>
<li>
<b>corba</b><br>
Independently buildable corba sources.
Currently uses Makefiles only, which will change in the future.
Requires a BOOTDIR jdk and optionally the langtools bootstrap tools.
</li>
<li>
<b>jaxp</b><br>
Independently buildable jaxp sources.
Uses a Makefile over an ant build script.
Requires a BOOTDIR jdk and optionally the langtools bootstrap tools.
</li>
<li>
<b>jaxws</b><br>
Independently buildable jaxws sources.
Uses a Makefile over an ant build script.
Requires a BOOTDIR jdk and optionally the langtools bootstrap tools.
</li>
<li>
<b>hotspot</b><br>
Independently buildable hotspot sources, mostly native code but
some Java code.
It does need access to a BOOTDIR javac during a build.
</li>
<li>
<b>j2se</b><br>
Independently buildable jdk, with access to a JDK_IMPORT_PATH.
Requires a BOOTDIR jdk and optionally the langtools bootstrap tools.
You can point it at the dist areas of 
langtools, corba, jaxp, and jaxws, for these classes, 
or it will pull the classes out of the
JDK_IMPORT_PATH rt.jar and tools.jar.
</li>
</ul>

<p>
The langtools component is built with the BOOTDIR jdk and creates
the jdk contribution files (dist/lib/classes.jar and dist/lib/src.zip)
for the resulting jdk image being built, plus bootstrap tools that
can be run with the BOOTDIR jdk for building the complete jdk
with the latest class versions etc.

<p>
The corba, jaxp, and jaxws components are given a BOOTDIR jdk to
build with (and optionally the langtools bootstrap files when
doing a full control build). All the components create contribution
files (dist/lib/classes.jar and dist/lib/src.zip).
Corba also contributes some special jdk image files (dist/bin.zip).

<p>
Build 22 continues to be our target for the last JDK7
promotion built via the TeamWare workspaces, the Build after
this one would be done via Mercurial repositories.
There is some risk to this target, and it's possible it might slip,
but it continues to be out target, and the momentum is building up.

<p>
There will still be a few SCCS keywords in the
Mercurial sources at first, but
these should be harmless. We'll continue to clean up the source as
we go.

</ul>

<p>
-kto

</body>
</html>

]]>

</content>
</entry>
<entry>
<title>OpenJDK Mercurial Transition Update 3</title>
<link rel="alternate" type="text/html" href="http://weblogs.java.net/blog/kellyohair/archive/2007/09/openjdk_mercuri_3.html" />
<modified>2008-02-13T18:05:20Z</modified>
<issued>2007-09-25T23:48:16Z</issued>
<id>tag:weblogs.java.net,2007:/blog/kellyohair/244.8318</id>
<created>2007-09-25T23:48:16Z</created>
<summary type="text/plain"> Update 3 Build 20 now contains a separate &quot;langtools&quot; (javac, javah, javap, apt, and javadoc) directory in the Build 20 source bundles. Build 21 (could be 22) will have separate corba, jaxp, and jaxws directories. Build 20 had some...</summary>
<author>
<name>kellyohair</name>

<email>Kelly.Ohair@Sun.COM</email>
</author>
<dc:subject>Community: JDK</dc:subject>
<content type="text/html" mode="escaped" xml:lang="en" xml:base="http://weblogs.java.net/blog/kellyohair/">
<![CDATA[<html>
<body>

<h2> Update 3 </h2>

<ul>
<p>
Build 20 now contains a separate "langtools" (javac, javah, javap, apt, and javadoc) directory in the Build 20 source bundles.

<p>
Build 21 (could be 22) will have separate corba, jaxp, and jaxws directories.
Build 20 had some duplicate javac tests between j2se and langtools, this should get corrected in Build 21, which should be out soon.

<p>
Build 22 continues to be our target for the last JDK7
promotion built via the TeamWare workspaces, the Build after
this one would be done via Mercurial repositories.
Then my co-workers might want to burn me at the stake, so I may
go into hiding for a while. ;^)

<p>
We have started to look at the various conventions
we want to put in place for things
like changeset comments, etc.
The general feeling is that the changeset comment should always
contain a bugid and synopsis, and not much else, pushing the bulk
of the data about a bug and it's fix into the bug database.
The Mercurial changeset itself serves as the exact changes
for a bug, so there is no need to save diffs or webrevs, just the
changeset global ID.

<p>
It has been agreed that the release engineering team will be creating
global tags for the various promotions, something like "jdk7-ea-b23",
so re-creating the sources as of a promotion should be easy.
(The fact that Mercurial makes it so easy to re-create accurate
source trees for any changeset or tag name may change the way we
deal with saving source bundles, or even creating source bundles.
Time will tell.

<p>
There may still be a few SCCS keywords in the sources at first, but
these should be harmless. We'll continue to clean up the source as
we go.

<p>
The current plan is to apply a source normalization script to the
Java and Native C/C++ sources as they transition from TeamWare to
Mercurial. The normalization procedure will attempt to clean up the
whitespace uses in the sources, expanding TABS, converting ^M characters, removing trailing blanks on lines, and making sure the file
ends with a newline character.
Hopefully we can put some hooks in place to prevent this kind of
whitespace clutter from coming back.
<ul>
<i><b>
(WHAT? NO TABS? ... yes, no tabs  ... ARE YOU NUTS? ... at times ...
WHY? ... because tabs create a source display problem ... BUT IT WORKS FINE FOR ME IN VI/EMACS! ...  yes, but what about everybody else?)
</b></i>
</ul>

</ul>

<p>
-kto

</body>
</html>

]]>

</content>
</entry>
<entry>
<title>OpenJDK Mercurial Transition Update 2</title>
<link rel="alternate" type="text/html" href="http://weblogs.java.net/blog/kellyohair/archive/2007/09/openjdk_mercuri_2.html" />
<modified>2008-02-13T18:05:20Z</modified>
<issued>2007-09-12T20:15:46Z</issued>
<id>tag:weblogs.java.net,2007:/blog/kellyohair/244.8230</id>
<created>2007-09-12T20:15:46Z</created>
<summary type="text/plain"> Update 2 The work to create OpenJDK/JDK7 Mercurial repositories is still progressing, we had a hickup getting the langtools split off from the j2se and it did not make Build 19 as you probably well know. We integrated the...</summary>
<author>
<name>kellyohair</name>

<email>Kelly.Ohair@Sun.COM</email>
</author>
<dc:subject>Community: JDK</dc:subject>
<content type="text/html" mode="escaped" xml:lang="en" xml:base="http://weblogs.java.net/blog/kellyohair/">
<![CDATA[<html>
<body>

<h2> Update 2 </h2>

<ul>
<p>
The work to create OpenJDK/JDK7 Mercurial repositories is still
progressing, we had a hickup getting the langtools
split off from the j2se and it did not make Build 19 as you probably
well know.
We integrated the split into Build 20 and have spent the last
2 weeks adjusting to the change. So
Build 20 will contain a separate "langtools" (javac, javah, javap, apt, and javadoc) directory in the Build 20 source bundles, which
will become a standalone Mercurial repository soon.

<p>
Build 20 also includes a great deal of Makefile changes and
minor changes to many files to remove SCCS keywords in the
sources and test files. We haven't fixed everything, but we
are making quite a bit of progress.

<p>
In Build 21 (or Build 22 as a backup) we hope to split
off corba, jaxp, and jaxws as separate openjdk repositories.
(At some later date, we may be able to better interface with
the corba, jaxp, and jaxws teams in terms of how they integrate
and how we accept changes from these areas into the jdk product,
so this is just step one).
Other changes in Build 21 and 22 will be around SCCS keyword
changes, and of course all the various teams are also integrating
changes all around us, which is to some degree why this is taking a bit longer.
Build changes often impact everyone, and we are dealing with a moving target.

<p>
We continue to target Build 22 (Build 23 as a backup) be the last
promotion built via the TeamWare workspaces, the Build after
this last TeamWare one would be done via Mercurial repositories.
Then at some point
after that, we can start working on providing those same
OpenJDK repositories on the openjdk website.

<p>
In other areas, we are starting to look at the various conventions
we want to put in place for things
like changeset comments, etc. and
how we will use Mercurial hooks to protect us from mistakes
and verify the conventions are followed.
</ul>

<h2>Build 20 Issues with regards to the langtools split</h2>

<ul>

<li>
You need 'ant' to build langtools, and you need to make sure the
environment variable ANT_HOME is set (especially on Windows).
</li>

<li>
When building from the control/make/Makefile, langtools is built
first, then the resulting 'dist' directory is supplied to the
j2se build via the variable ALT_LANGTOOLS_DIST.
The langtools dist/bootstrap/javac.jar is then run with the BOOT jdk (ALT_BOOTDIR)
to create all the resulting jdk classes for the build.
<br>
<b>IF</b> langtools is not built or not found, then the javac
launcher from the ALT_JDK_IMPORT_PATH is run (a partial jdk build).
This ALT_JDK_IMPORT_PATH is assumed to be a recent jdk7 build,
or at least recent enough to handle building the jdk7 itself.
<br>
It's acceptable to set ALT_BOOTDIR and ALT_JDK_IMPORT_PATH to
the same jdk7, and might even work if they both refer to
the same jdk6, but no guarantees.
<br>
ALT_JDK_IMPORT_PATH continues to be the place to import parts of
a jdk that a partial build has chosen to not build, but it
is also now a backup place to get a javac when the langtools
dist area is not available.
</li>

<li>
Prior to the langtools split, the jdk was built in a somewhat
bootstrap process, primarily because the javac sources were part
of the rest of the jdk.
Now that javac is separate, and can be run with a BOOT jdk,
the thought was that the entire jdk could be built without actually
being run during the build process, a great simplification
and a benefit to anyone doing cross-platform builds.
Unfortunately, it turns out that the build procedure relied on a few
tools like rmic, idlj, native2ascii, and javazic be
run from the freshly built classes of these tools in the jdk source.
So for the time being, these tools will be run from the BOOT jdk
or run via the BOOT jdk until we can resolve these issues.
The actual jdk install image (e.g. rt.jar tools.jar etc.)
 is now created before it is run now,
although the image is massaged a little after it's initial image
is created.
</li>

</ul>

<p>
-kto

</body>
</html>

]]>

</content>
</entry>
<entry>
<title>OpenJDK Mercurial Transition Update 1</title>
<link rel="alternate" type="text/html" href="http://weblogs.java.net/blog/kellyohair/archive/2007/08/openjdk_mercuri.html" />
<modified>2008-02-13T18:05:20Z</modified>
<issued>2007-08-22T02:00:33Z</issued>
<id>tag:weblogs.java.net,2007:/blog/kellyohair/244.8070</id>
<created>2007-08-22T02:00:33Z</created>
<summary type="text/plain"> The work to create OpenJDK/JDK7 Mercurial repositories is progressing, but before I tell you anything significant, I&apos;ll bore you with some basic details about JDK building. ;^) JDK Build Promotions First, let me explain a little about the JDK...</summary>
<author>
<name>kellyohair</name>

<email>Kelly.Ohair@Sun.COM</email>
</author>
<dc:subject>Community: JDK</dc:subject>
<content type="text/html" mode="escaped" xml:lang="en" xml:base="http://weblogs.java.net/blog/kellyohair/">
<![CDATA[<html>
<body>

<p>
The work to create OpenJDK/JDK7 Mercurial repositories is progressing,
but before I tell you anything significant, I'll bore you
with some basic details about JDK building. ;^)


<h2>JDK Build Promotions</h2>

<ul>
<p>
First, let me explain a little about the JDK build promotions.
The build promotion cycle for active releases
is usually 1 or 2 weeks long, and currently
for JDK7 it's 2 weeks. That means that roughly every 2 weeks, a
promoted JDK7 build is made available at the
<a href="https://jdk7.dev.java.net/">jdk7.dev.java.net</a>
binary bundle area (plus the JRL source bundle area), and also at the
<a href="http://openjdk.java.net/">OpenJDK.java.net</a>
source bundle area. I assume people see the emails sent out on
promotions to
the announce@openjdk.java.net alias (subscribe at the
<a href="http://mail.openjdk.java.net/mailman/listinfo">openjdk mailing lists</a>
site).

<p>
Between promotions, 
individuals integrate their JDK7 changes
into the various team integration areas, and
the teams will then integrate their changes into the
MASTER JDK7 source workspaces.
The MASTER source workspaces are like the Pacific Ocean,
with all the various teams sending
their changes to the MASTER repositories like water flowing through
the various rivers, lakes, etc. into the Pacific.
At any point the changes might get held up or inspected by
a "gate keeper" or "integrator", like the dam operators on rivers
(that's "dam operators", not "damn operators").
Ok ok, strange analogy, but it kind of fits.
In any case, sometimes a change looks like it might
make it into the MASTER workspaces and into a build promotion,
but it doesn't, some gate keeper might
scoop it out of the river, or some bear might drink it or something
(some bears might also make contribution to the river,
 but let's not go there, most of the pesky bears have been relocated
 north of here).
Ultimately if a change doesn't make a promotion and isn't permanently
diverted, it will make the next promotion, or the one after that,
just depends on how far it has to go.
(And yes, testing is part of this process, the water is
indeed safe to drink).

<p>
The schedule for when build promotions will happen is fairly
predictable, but anything can happen, and sometimes they get
delayed. The current schedule is...  <b>HA, you thought I was
going to give you hard dates!</b> ...  well ok, why not, but
these are estimated dates, and sometimes you need to add a day
to the final promotion day
before the actual bundles are available on the
jdk7.dev.java.net and openjdk.java.net sites:

<ul>
<li>
JDK7 Build 19 final - <i>estimated</i> Aug 31
</li>
<li>
JDK7 Build 20 final - <i>estimated</i> Sept 14
</li>
<li>
JDK7 Build 21 final - <i>estimated</i> Sept 28
</li>
<li>
JDK7 Build 22 final - <i>estimated</i> Oct 12
</li>
<li>
JDK7 Build 23 final - <i>estimated</i> Oct 26
</li>
</ul>

<p>
If a build slips, all the following build promotion
dates have to be permanently adjusted.
These build promotion
dates are probably no big surprise, anyone could
look at the past delivery of JDK7 build promotions and guessed
this much. But I wanted to attach at least some preliminary dates
to some build numbers so you understand the planning a bit.

<p>
Note that once we get into delivering Mercurial repositories,
the whole "time frame" as to when you see source changes
is drastically different.
The traditional
source bundles become less interesting, except for maybe archiving.
And even after Mercurial,
the JDK Build Promotions will continue, and the binary bundles
and all deliveries to jdk7.dev.java.net won't change much.
</ul>


<h2>The "langtools" Separation</h2>

<ul>
<p>
Second, hopefully in Build 19 (backup plan is Build 20)
we will be doing
some major restructuring of the j2se workspace.
This first restructuring is called the "langtools" separation.
The "langtools" are the tools javac, javah, javap, javadoc, and apt.
This change is significant because it removes the fairly
complicated javac "recompile" cycle from the j2se build, and
greatly simplifies the j2se build (many Makefiles get deleted).
It introduces another tree of sources (about 3,000 files)
with the name "langtools".

<p>
No, it doesn't mean the entire j2se build can convert to ant.
</ul>


<h2>Other Changes</h2>

<ul>
<p>
Third, in Builds 20 through 22 or 22, there may be additional
restructurings and things like SCCS keyword removals.
</ul>

<h2>The Transition</h2>

<ul>
<p>
Lastly, we sincerely hope that Build 22 or 23 will be the last
promotion built with TeamWare sources, meaning that at some point
after those promotions we can start working on making the
OpenJDK repositories available, probably fairly quickly in terms
of a read-only state.
</ul>

<h2>Mercurial Transition Details</h2>

<ul>
<p>
Just to make sure people are aware of some of the technical details of
how the transformation will happen:

<ul>
<li>
A Set of Repositories
<p>
Keep in mind that we are talking about a set of repositories, not
just one.
The current repository set is: control, langtools, j2se, and hotspot.
A one-to-one mapping from the TeamWare workspaces to the
Mercurial repositories will be maintained at transition time.
(Although we had plans for a Mercurial forest, and may use them
eventually, for now the OpenJDK repositories will likely
just be a set of separate repositories).
<p>
And more important, we are probably talking many different sets
of repositories, one set for the MASTER repositories which
are read-only to everyone except the gate keepers or integrators,
plus potentially a set of repositories for each of the
team integration areas. The specific details remains to be seen.
With a
<a href="http://en.wikipedia.org/wiki/Distributed_revision_control">
DSCM</a>
system like Mercurial or TeamWare, you usually end up with the
Ocean and rivers analogy I mentioned above, with changes trickling
in over time, from various team integration areas.
Just looking at the MASTER level may be appropriate for some,
but for others, particular team integration areas may be of more
interest. The patterns we have used over the years with TeamWare
will map pretty much the same way to Mercurial.
</li>
<li>
History of Past Changes
<p>
No past history of the sources will be included (for legal reasons we can't provide history prior to the launch, and for technical reasons
we decided to not provide the TeamWare history between the launch and
the transition).
Effectively each file will be 'sccs edit'd out of the TeamWare
workspace, and added to a Mercurial repository.
</li>
</ul>
</ul>

<h2>Conclusion</h2>

<p>
Hope this was helpful.
This project has been extremely hard to predict, and I'm still not
sure that some evil issue won't de-rail the plans, but hopefully
this keeps you all informed.

<p>
It will be over soon, I hope, as you can tell from my writing
I'm getting a little dingy (no I'm not getting a small boat). ;^)

<p>
-kto

</body>
</html>

]]>

</content>
</entry>
<entry>
<title>OpenJDK Builds (Solaris &amp; Linux)</title>
<link rel="alternate" type="text/html" href="http://weblogs.java.net/blog/kellyohair/archive/2007/05/openjdk_builds.html" />
<modified>2008-02-13T18:05:20Z</modified>
<issued>2007-05-08T23:13:55Z</issued>
<id>tag:weblogs.java.net,2007:/blog/kellyohair/244.7304</id>
<created>2007-05-08T23:13:55Z</created>
<summary type="text/plain"> OpenJDK Builds (Solaris &amp; Linux) Anyone building the new OpenJDK bundles from openjdk.java.net should find that this is an easier build procedure than the JRL building from jdk7.dev.java.net. First off, it&apos;s just the basic JDK sources, no plugin or...</summary>
<author>
<name>kellyohair</name>

<email>Kelly.Ohair@Sun.COM</email>
</author>
<dc:subject>Community: JDK</dc:subject>
<content type="text/html" mode="escaped" xml:lang="en" xml:base="http://weblogs.java.net/blog/kellyohair/">
<![CDATA[<html>
<body>
<h1>OpenJDK Builds (Solaris & Linux)</h1>

<p>
Anyone building the new OpenJDK bundles from
<a href="http:/openjdk.java.net">openjdk.java.net</a>
should find that this is an easier build procedure than
the JRL building from 
<a href="http://jdk7.dev.java.net">jdk7.dev.java.net</a>.

<p>
First off, it's just the basic JDK sources, no plugin or installer
bundling logic has been included yet. Also the special version of
Motif is not included for Linux builds,
but only some of the include files are
needed and they can easily be downloaded from various locations
or even installed via official Linux distributions.

<p>
Second, there are a few small pieces that we still have legal issues
with. So you'll see mention of "Binary Plugs" in the build process.
This means that we have provided you the binary versions for these
pieces, and they will be copied into your OpenJDK build during the
build process. Note that you need the correct "Binary Plug" bundles
from www.openjdk.org's Download area.

<p>
Third, the Rhino javascript classes are not in the OpenJDK, but are available from
<a href="http://www.mozilla.org/rhino/">http://www.mozilla.org/rhino/</a>
(there were some license issues here).

<p>
Fourth, ... I'm sure I forgot something...  I'll re-edit this post
when I remember. :^(

<p>
-kto

<p>
P.S. Windows builds will not work at this time.

<p>
P.P.S. On Solaris you need the Sun Studio 11 compilers, but if you
build on Solaris Express, the Sun Studio 11 compilers are already
installed.
</body>
</html>]]>

</content>
</entry>
<entry>
<title>JDK Builds on Windows</title>
<link rel="alternate" type="text/html" href="http://weblogs.java.net/blog/kellyohair/archive/2007/01/jdk_builds_on_w.html" />
<modified>2008-02-13T18:05:20Z</modified>
<issued>2007-01-25T20:33:07Z</issued>
<id>tag:weblogs.java.net,2007:/blog/kellyohair/244.6411</id>
<created>2007-01-25T20:33:07Z</created>
<summary type="text/plain"> I need to add this to the JDK build documentation, but it may be helpful to have it posted here for some people. Building the JDK on Windows can be difficult at times, so if it hasn&apos;t been mentioned...</summary>
<author>
<name>kellyohair</name>

<email>Kelly.Ohair@Sun.COM</email>
</author>
<dc:subject>Community: JDK</dc:subject>
<content type="text/html" mode="escaped" xml:lang="en" xml:base="http://weblogs.java.net/blog/kellyohair/">
<![CDATA[<p>
I need to add this to the JDK build documentation, but it may be
helpful to have it posted here for some people.

<p>
Building the JDK on Windows can be difficult at times, so if it 
hasn't been mentioned before, here are a few clues:

<ul>
<li>
When using MKS, make sure that the PATH setting has the
<tt>${ROOTDIR}/mksnt</tt> and
<tt>${ROOTDIR}/bin</tt> directories <b>BEFORE</b> the system
paths. 
Ideally they should be the first items in your PATH.
There are conflicts between the MKS tools and what is supplied
in Windows, and you don't want a mixture.
<ul>
<i>
I cannot verify or reproduce this, 
but there might be some kind of issue
regarding long PATH values on Windows. 
Even with MKS in the right
order in PATH, if many paths are placed before MKS, 
sometimes this doesn't work.
So my recommendation is is to place MKS very early in PATH.
</i>
</ul
</li>
<li>
When using CYGWIN, the same thing is true, make sure 
<tt>/usr/bin</tt> is
before the system directories.
Mixtures of tools will often not
work.
</li>
<li>
Use an MKS shell when you start the <tt>gnumake.exe</tt>
(GNU make built for MKS).
Starting make in a Windows 
<tt>cmd.exe</tt> command window will often not work.
</li>
<li>
Use a CYGWIN shell when you start the 
<tt>/usr/bin/make</tt> of CYGWIN, if you don't you might get an error like: <pre><code>/bin/sh: cannot duplicate fd 31 to fd 0: Bad file descriptor</code></pre>
</li>
<li>
The 3.81 version of make (in the latest CYGWIN) does not
understand paths that use a drive letter like <tt>C:\</tt>
or <tt>C:/</tt>. Which means you cannot use this version of
GNU make to build the JDK. 
It sounds like this is being fixed but it may take some time
to get the latest CYGWIN fixed.
You need make version 3.78.1 to 3.80, maybe 3.82 if this
problem is addressed in tha version, although it sounds like
it's a matter of how you build GNU make perhaps?
So get an older version of the make command.
</li>
<li>
There have been some reports of the latest <tt>find</tt>
command in CYGWIN is also broken
(version 4.3.2 as reported by Dmitri), perhaps with the
drive letter path names too.
So get an older version 
(Dmitri recommends 4.3.0) of the find command.
</li>
<li>
If you are building JDK5, you may need to
<br>
 <tt>unset TMPDIR</tt>
<br>
 <tt>unset TMP</tt> 
<br>
in your
environment.
The JDK5 makefiles used these as make variables and they
can cause conflicts with the environment variable version used
by MKS. I don't know if this is also a problem with CYGWIN
since JDK5 didn't build very reliably with CYGWIN anyway.
In JDK6, the makefiles were changed to not use these names.
</li>
<li>
The Windows Visual Studio compiler you are using should
be in your PATH.
You can't run the <tt>cl.exe</tt> compilers with a full path like <tt>C:/<i>...</i>/Bin/cl.exe</tt> without also having that
<tt>Bin</tt> in your PATH settings.
If you get an error message that says something about
not being able to get CC_VERSION, then try running <tt>cl</tt>
yourself in the same shell, perhaps compile and link a small
hello world program to verify that <tt><cl</tt> works from
the shell command line.
</li>
<li>
When setting the JDK <tt>ALT_*</tt> variables in your environment
use the pathname style of 
"<tt>C:/</tt>", not "<tt>C:\</tt>" 
or CYGWIN's "<tt>/cygdrive/C/</tt>".
Ideally, you should also try and use the path names without
spaces 
(see MKS <tt>dosname -s</tt> and CYGWIN <tt>cygpath -s -m</tt>).
With JDK6, many <tt>ALT_*</tt>
 variables should not need to be set and
the makefiles should figure it all out, so try using as few
<tt>ALT_*</tt> variables as possible.
The one exception is <tt>ALT_UNIXCOMMAND_PATH</tt> for CYGWIN,
which is by default <tt>/usr/bin</tt>, but should be a CYGWIN
style path if you need to set it for some bizarre reason.
</li>
</ul>

<p>
Hope these tidbits are helpful to somone.

<p>
-kto
]]>

</content>
</entry>
<entry>
<title>JVM TI Agents Article</title>
<link rel="alternate" type="text/html" href="http://weblogs.java.net/blog/kellyohair/archive/2007/01/jvm_ti_agents_a_1.html" />
<modified>2008-02-13T18:05:20Z</modified>
<issued>2007-01-17T18:29:37Z</issued>
<id>tag:weblogs.java.net,2007:/blog/kellyohair/244.6346</id>
<created>2007-01-17T18:29:37Z</created>
<summary type="text/plain"> Just a plug (and additional reference) on my December 2006 article on JVM TI at http://java.sun.com/developer/technicalArticles/J2SE/jvm_ti. I really had not expected this article to be very popular, but I was assuming that only people writing JVM TI agents would...</summary>
<author>
<name>kellyohair</name>

<email>Kelly.Ohair@Sun.COM</email>
</author>
<dc:subject>Community: JDK</dc:subject>
<content type="text/html" mode="escaped" xml:lang="en" xml:base="http://weblogs.java.net/blog/kellyohair/">
<![CDATA[<p>
Just a plug (and additional reference) on my December 2006
<a href=http://java.sun.com/developer/technicalArticles/J2SE/jvm_ti>
article</a>
 on 
<a href=http://java.sun.com/javase/6/docs/technotes/guides/jvmti/index.html>
JVM TI</a>
at
<a href=http://java.sun.com/developer/technicalArticles/J2SE/jvm_ti/>
http://java.sun.com/developer/technicalArticles/J2SE/jvm_ti</a>.

<p>
I really had not expected this article to be very popular, but 
I was assuming that only people writing JVM TI agents
would be interested. 
It appears there is quite a bit of general curiosity on VM agents.
Of course the 
<a href=http://www.javalobby.org/java/forums/t87039.html>
Java Lobby</a>
and
<a href=http://sun.systemnews.com/articles/106/4/ja/17426>
Sun System News</a> links helped too.  :^)

<p>
Big thanks to Janice for all her help with this article!
It would never have read as well without her help.

<p>
Just for reference, 
there is also a JVMPI to JVM TI conversion article at:
<a href=http://java.sun.com/developer/technicalArticles/Programming/jvmpitransition/>
http://java.sun.com/developer/technicalArticles/Programming/jvmpitransition/</a>.

<p>
-kto]]>

</content>
</entry>
<entry>
<title>My Ant Adventure (Updated 1/23/2007)</title>
<link rel="alternate" type="text/html" href="http://weblogs.java.net/blog/kellyohair/archive/2007/01/my_ant_adventur.html" />
<modified>2008-02-13T18:05:20Z</modified>
<issued>2007-01-03T21:46:25Z</issued>
<id>tag:weblogs.java.net,2007:/blog/kellyohair/244.6246</id>
<created>2007-01-03T21:46:25Z</created>
<summary type="text/plain"><![CDATA[ Update for 1/23/2007, just a very short note on windows. The findbugs target needs to add vmlauncher="false", so the line: &lt;exec executable="findbugs" failonerror="true"&gt; changes to &lt;exec executable="findbugs" failonerror="true" vmlauncher="false"&gt; It's not exactly clear why this is necessary, but this...]]></summary>
<author>
<name>kellyohair</name>

<email>Kelly.Ohair@Sun.COM</email>
</author>
<dc:subject>Community: JDK</dc:subject>
<content type="text/html" mode="escaped" xml:lang="en" xml:base="http://weblogs.java.net/blog/kellyohair/">
<![CDATA[<p>
Update for 1/23/2007, just a very short note on windows.
<ul>
<p>
<u><b>
The findbugs target needs to add vmlauncher="false", so the line:
</b></u>
<ul>
<tt>&lt;exec executable="findbugs" failonerror="true"&gt;</tt>
</ul>
<p>
changes to
<ul>
<tt>&lt;exec executable="findbugs" failonerror="true" vmlauncher="false"&gt;</tt>
</ul>
<p>
<u><b>
It's not exactly clear why this is necessary, but this allows
the findbugs target to work on windows, and also works everywhere else. The findbugs -version exec was also removed because this
will trigger the GUI to start up if it runs findbugs.bat,
and findbugs.bat doesn't seem to have a -version option.
<p>
In addition, the ant 1.7.0 install bits seem to have a windows
<tt>bin/ant.cmd</tt> file that does not have execute permissions,
by adding execute permissions to this file, ant can be run from a
Makefile. Again, it's not exactly clear why this is needed, but
it makes sense for it to have execute permissions, so this seems
harmless.
</b></u>
</ul>

<p>
Updated 1/22/2007, tried to mark 
changes in <b><u>bold underline</u></b>.
Also added the actual
<a href="http://weblogs.java.net/blog/kellyohair/archive/build.xml">
build.xml</a>
to download.

<p>
Now I have never liked ants (see my
<a href=http://blogs.sun.com/kto/entry/ants>ants</a>
blog), but
this story is about my adventure with the 
<a href=http://ant.apache.org/>Apache Ant</a>
build system.
I can safely say that I still hate ants, all ants, but even ants
have a place in the world, ant build scripts included.

<p>
So I was crawling along with my little
<a href=http://www.netbeans.org>NetBeans</a>
Java project just happy as a clam using NetBeans 5.5 with the
<a href=http://findbugs.sourceforge.net/>findbugs</a>
<a href=https://sqe.dev.java.net/>plugin</a>,
and the
<a href=http://junit.sourceforge.net/>JUnit</a>
tests that NetBeans help me to create and run so easily.
I never had to write an Ant script before, I just pointed NetBeans
at my sources, set a few properties and
let NetBeans handle it. Overall it was pretty easy, and simple.

<p>
But when it came time for a batch product build, I had used a Makefile and a separate build process. So the romantic picnic at the park was over, it was time
for the ants to take over. :^)
The Makefile worked, but
wasn't ideal, and it was always a temporary thing, but
it did create the bin scripts and run some bin script tests
that I hadn't managed to get the NetBeans building to do.

<p>
First off, it's never good to have two different ways to build a product, you never know for sure if the two build mechanisms really built the same thing. So in general, when it comes to a build process,
everyone should follow the 
<a href=http://en.wikipedia.org/wiki/Highlander_%28film%29>Highlander</a>
rule of "There can be only one".
Granted, a "development build" will always be slightly different,
probably a subset, but it should be using the same basic mechanisms
as a more formal and complete product build.

<p>
Second, I was missing some of the things I wanted built into the batch
build process, namely running findbugs and running all my JUnit tests.
So I wasn't happy with my existing batch build process.

<p>
Ideally I want a batch build process to:

<ol>
<li>
compile with
full javac error checking and treat all errors as fatal
(javac -Xlint:all -Werror)
</li>
<li>
construct the
'dist' area (the jar file and including any necessary bin scripts)
</li>
<li>
run all the JUnit tests
</li>
<li>
run the bin script tests
</li>
<li>
run javadoc and treat all errors as fatal
</li>
<li>
run findbugs with full checking and treat all errors as fatal
</li>
</ol>

<p>
Lucky for me I've got a very clean set of source files, and I
want to keep them that way, otherwise I'd have to back off on some
of my "<b>treat all errors as fatal</b>" requirements. ;^)
The first two items above represent the typical development
build or "full build"
while inside NetBeans, but it was important to me that all the
steps should be manually runnable inside NetBeans too.

<p>
So I started my adventure to make this happen.

<p>
My first thought was about having the Makefile
run findbugs and JUnit directly,
but that seemed wrong and didn't solve
my first problem above. So the answer was fairly obvious, if I
needed a Makefile, it would be trivial to have it run
the ant script, right? So I just needed to create an ant script.
Of course it's never that easy. I did manage to get this to work,
and I did learn enough about ant to create this standalone ant script,
one that did everything I wanted, but it was NOT simple and easy,
and the end result
was not very satisfactory.

<p>
It turns out that when you create a NetBeans project with
an existing ant script, some of the NetBeans features
(like debugging a JUnit test) will not work. :^(
So some NetBeans features (or what I perceive to be features) are tied to the specific ant build scripts that
NetBeans creates.

<p>
Then there were the ant problems, which involved having a
version of ant that would work with the latest
<a href=http://findbugs.sourceforge.net/manual/anttask.html>findbugs</a>
ant task and the
<a href=http://junit.sourceforge.net/doc/faq/faq.htm#running_5>junit</a>
ant task. I finally settled on using ant 1.7 but
since I allow for my project to build anywhere, I needed ant 1.7
everywhere, and that meant I had to manage my own version of ant
(I could not trust all systems to have an ant that would work for me).
I think the ant inside NetBeans 5.5 was 1.6 something, and it
didn't work with the findbugs ant task for some reason, but that was ok because while
inside NetBeans you really want to use the findbugs plugin for the
best interaction with your sources.
So I finally gave up on the findbugs ant task and just used:

<ul>
<pre>
<code>
   &lt;condition property="findbugs.home" value="/Applications/findbugs"&gt;
        &lt;os family="mac"/&gt;
    &lt;/condition&gt;
    
    &lt;target name="findbugs-batch" depends="init"
            description="Run findbugs in batch mode"&gt;
        &lt;exec 
            executable="${findbugs.home}/bin/findbugs"
            failonerror="true"&gt;
            &lt;arg value="-textui"/&gt;
            &lt;arg value="-effort:max"/&gt;
            &lt;arg value="-low"/&gt;
            &lt;arg path="${dist.jar}"/&gt;
        &lt;/exec&gt;
    &lt;/target&gt;
</code>
</pre>
</ul>

<p>
<b><u>
An <b>UPDATE</b> on this. 
Turns out that Windows is giving me
no end of grief regarding pathnames, 
so this was changed to assume findbugs was in
the PATH setting, overall this seems to make life easier.
In general avoiding having ant deal with full paths is ideal,
that also means avoiding the ant property <tt><b>${basedir}</b></tt>
which WILL be a full path.
The Makefile changed too, see below.
I want this ant script
to work on MacOSX, Solaris, Linux, and Windows, others
may not have this requirement.
I also wanted it to work no matter where the source 
was moved to, so again, avoid fullpaths.
I also added the findbugs
-exitcode option so that errors trigger a
non-zero process exit code and also the
-maxHeap 512 option to give findbugs lots of heap space 
(it seems to need it, and runs a bit faster this way).
So now I use something more like:
</u></b>

<ul>
<pre>
<code>
    &lt;target name="myfindbugs" depends="init"
            description="Run findbugs in batch mode"&gt;
        &lt;exec 
            executable="findbugs"
            failonerror="true"&gt;
            &lt;arg value="-maxHeap"/&gt;
            &lt;arg value="512"/&gt;
            &lt;arg value="-textui"/&gt;
            &lt;arg value="-effort:max"/&gt;
            &lt;arg value="-low"/&gt;
            &lt;arg value="-exitcode"/&gt;
            &lt;arg path="${dist.jar}"/&gt;
        &lt;/exec&gt;
    &lt;/target&gt;
</code>
</pre>
</ul>

<p>
As it turns out, because using the 
findbugs ant task
causes the ant VM to run out of memory, so you had to restart ant
with more memory, what a pain.
Using my above batch target the findbugs process
uses it's own VM. This really doesn't change the performance much since findbugs takes a few minutes to run anyway, and just using the bin findbugs script must set the max memory up higher or something.

<p>
So now I had to deal with this loss of NetBeans Junit debug
capability.
I did like how NetBeans automatically created the menu for the
targets in my build.xml file, but I could not live without the
ability to quickly debug any JUnit test. So I needed to either
configure my build.xml file better, or try another approach.

<p>
So I went back to letting NetBeans create it's own ant scripts
and when I found where NetBeans placed these files (build.xml plus the nbproject directory), 
I just copied over all the nbproject directory and the build.xml
file to my project's 
<a href=http://www.selenic.com/mercurial/wiki/index.cgi>Mercurial</a>
repository and reopened the repository as a 
pre-configured NetBeans project.
That way I didn't have to worry about matching the NetBeans ant
conventions to get the JUnit debug feature to work.

<p>
<b><u>
An update on this, first, do NOT include the nbproject/private directory
in your repository.
And second,
if you tell NetBeans to use anything other than the default
Java platform, things don't work very well.
This was easy for me to avoid, but the way the Java platforms
are defined in the ant scripts didn't make the files transportable.
Maybe this was a Mac specific thing?
</u></b>

<p>
Then I edited the NetBeans generated build.xml file
(which is now my primary product build.xml file) and
added to it.

<ul>
<li>
<b><u>
Some properties and hooks into the NetBeans ant scripts I needed
to set for some reason.
Some of these properties
should not need to be set since they are set for you
already in the nbproject files, so I'm puzzled why you have to set
property values sometimes and not others.
You will also notice the echo targets I have created, which is
just my style, I like to know when targets are being run, and the
ant verbose option is too verbose, so I added appropriate echo
commands.
</u></b>
<br>
<pre>
<code>
    &lt;!-- project name (determines jar and script name) --&gt;
    &lt;property name="project.name"           value="jprt"/&gt;
    
    &lt;!-- top level package name --&gt;
    &lt;property name="package.name"           value="jprt"/&gt;
    
    &lt;!-- top level paths --&gt;
    &lt;property name="src.dir"                value="src"/&gt;
    &lt;property name="test.src.dir"           value="test"/&gt;
    &lt;property name="lib.dir"                value="lib"/&gt;
    
    &lt;!-- source paths --&gt;
    &lt;property name="bin.src"                value="${src.dir}/bin"/&gt;
    &lt;property name="sbin.src"               value="${src.dir}/sbin"/&gt;
    &lt;property name="doc.files.src"          value="${src.dir}/${package.name}/doc-files"/&gt;
    
    &lt;!-- build paths --&gt;
    &lt;property name="build.dir"              value="build"/&gt;
    &lt;property name="manifest.file"          value="${build.dir}/mainfest.mf"/&gt;
    &lt;property name="build.classes.dir"      value="${build.dir}/classes"/&gt;
    &lt;property name="build.test.classes.dir" value="${build.dir}/test/classes"/&gt;
    
    &lt;!-- dist paths --&gt;
    &lt;property name="dist.dir"               value="dist"/&gt;
    &lt;property name="bin.dir"                value="${dist.dir}/bin"/&gt;
    &lt;property name="sbin.dir"               value="${dist.dir}/sbin"/&gt;
    &lt;property name="dist.jar"               value="${dist.dir}/${project.name}.jar"/&gt;
    
    &lt;!-- path to test scripts  --&gt;
    &lt;property name="test.script"            value="${test.src.dir}/test.sh"/&gt;
    &lt;property name="test.system.script"     value="${test.src.dir}/test_system.sh"/&gt;
    
    &lt;!-- javadoc paths --&gt;
    &lt;property name="dist.javadoc.dir"       value="${dist.dir}/javadoc"/&gt;
    &lt;property name="doc.files"              value="${dist.javadoc.dir}/${package.name}/doc-files"/&gt;
    
    &lt;!-- classpath settings --&gt;
    &lt;property name="javac.classpath"        value=""/&gt;
    &lt;property name="run.classpath"          value="${build.classes.dir}"/&gt;
    &lt;property name="javac.test.classpath"   value="${build.classes.dir}:${lib.dir}/junit.jar"/&gt;
    &lt;property name="run.test.classpath"     value="${build.test.classes.dir}:${javac.test.classpath}"/&gt;
    
    &lt;!-- default system options --&gt;
    &lt;condition property="system.instance" value="testsystem-ant"&gt;
        &lt;not&gt; &lt;isset property="system.instance"/&gt; &lt;/not&gt;
    &lt;/condition&gt;
    
    &lt;!-- always provide debugging information --&gt;
    &lt;property name="javac.debug"            value="true"/&gt;
    
    &lt;!-- the main class for the project --&gt;
    &lt;property name="main.class"             value="${package.name}.tools.Main"/&gt;
    
    &lt;!-- make sure netbeans knows we have a manifest file --&gt;
    &lt;property name="manifest.available"     value="true"/&gt;

    &lt;!-- hooks into netbeans ant files --&gt;
    &lt;target name="-pre-compile"             depends="mycompilestart"/&gt;
    &lt;target name="-post-compile"            depends="mycompileend"/&gt;
    &lt;target name="-do-jar-with-manifest"    depends="mymanifest"/&gt;
    &lt;target name="-pre-jar"                 depends="myjarstart,mymanifest"/&gt;
    &lt;target name="-post-jar"                depends="myjarend,mybinfiles,mysbinfiles,mypropfiles,myjartests"/&gt;
    &lt;target name="javadoc"                  depends="myjavadoc"/&gt;

</pre>
</code>
</li>
<li>
The special targets of my own:
<br>
<pre>
<code>
    &lt;!-- just used to add messages at certain points --&gt;
    &lt;target name="mycompilestart"&gt; &lt;echo message="COMPILING"/&gt;           &lt;/target&gt;
    &lt;target name="mycompileend"&gt;   &lt;echo message="COMPILING COMPLETED"/&gt; &lt;/target&gt;
    &lt;target name="myjarstart"&gt;     &lt;echo message="BUILDING JAR"/&gt;        &lt;/target&gt;
    &lt;target name="myjarend"&gt;       &lt;echo message="JAR COMPLETED"/&gt;       &lt;/target&gt;
    
    &lt;!-- create my own manifest file --&gt;
    &lt;target name="mymanifest" description="Create manifest file"&gt;
        &lt;echo message="Creating manifest file: ${manifest.file}"/&gt;
        &lt;manifest file="${manifest.file}"&gt;
            &lt;attribute name="Built-By"   value="${user.name}"/&gt;
            &lt;attribute name="Main-Class" value="${main.class}"/&gt;
        &lt;/manifest&gt;
    &lt;/target&gt;
    
    &lt;!-- copy the bin files --&gt;
    &lt;target name="mybinfiles" description="Create bin files"&gt;
        &lt;echo message="Populating bin files"/&gt;
        &lt;mkdir dir="${bin.dir}"/&gt;
        &lt;copy todir="${bin.dir}"&gt;
            &lt;fileset dir="${bin.src}" casesensitive="yes"&gt;
                &lt;include name="*"/&gt;
            &lt;/fileset&gt;
        &lt;/copy&gt;
        &lt;chmod dir="${bin.dir}" perm="ugo+rx" includes="*"/&gt;
    &lt;/target&gt;
    
    &lt;!-- copy the sbin files --&gt;
    &lt;target name="mysbinfiles" description="Create sbin files"&gt;
        &lt;echo message="Populating sbin files"/&gt;
        &lt;mkdir dir="${sbin.dir}"/&gt;
        &lt;copy todir="${sbin.dir}"&gt;
            &lt;fileset dir="${sbin.src}" casesensitive="yes"&gt;
                &lt;include name="*"/&gt;
            &lt;/fileset&gt;
        &lt;/copy&gt;
        &lt;chmod dir="${sbin.dir}" perm="ugo+rx" includes="*"/&gt;
    &lt;/target&gt;
    
    &lt;!-- copy the property files into the sbin directory --&gt;
    &lt;target name="mypropfiles" description="Create sbin property files"&gt;
        &lt;echo message="Populating ${dist.dir} with prop files"/&gt;
        &lt;mkdir dir="${dist.dir}"/&gt;
        &lt;copy todir="${dist.dir}"&gt;
            &lt;fileset dir="${src.dir}" casesensitive="yes"&gt;
                &lt;include name="*.properties"/&gt;
            &lt;/fileset&gt;
        &lt;/copy&gt;
        &lt;echo message="System instance: ${system.instance}"/&gt;
        &lt;!-- Ant echo is Broken: &lt;echo file="${dist.dir}/config-default.properties"
              message="jprt.system.instance=${system.instance}"/&gt; --&gt;
        &lt;exec executable="echo" failonerror="true"
              output="${dist.dir}/config-default.properties"&gt;
            &lt;arg value="jprt.system.instance=${system.instance}"/&gt;
        &lt;/exec&gt;
    &lt;/target&gt;
    
    &lt;!-- test the jar file --&gt;
    &lt;target name="myjartests" description="Test jar."&gt;
        &lt;echo message="Testing: java -jar ${dist.jar} "/&gt;
        &lt;java jar="${dist.jar}" fork="true" failonerror="true"&gt;
            &lt;assertions&gt; &lt;enable/&gt; &lt;/assertions&gt;
        &lt;/java&gt;
        &lt;echo message="Testing: java -jar ${dist.jar} help"/&gt;
        &lt;java jar="${dist.jar}" fork="true" failonerror="true"&gt;
            &lt;arg value="help"/&gt;
            &lt;assertions&gt; &lt;enable/&gt; &lt;/assertions&gt;
        &lt;/java&gt;
        &lt;echo message="Testing: java -jar ${dist.jar} usage"/&gt;
        &lt;java jar="${dist.jar}" fork="true" failonerror="true"&gt;
            &lt;arg value="usage"/&gt;
            &lt;assertions&gt; &lt;enable/&gt; &lt;/assertions&gt;
        &lt;/java&gt;
        &lt;echo message="Testing: java -jar ${dist.jar} version"/&gt;
        &lt;java jar="${dist.jar}" fork="true" failonerror="true"&gt;
            &lt;arg value="version"/&gt;
            &lt;assertions&gt; &lt;enable/&gt; &lt;/assertions&gt;
        &lt;/java&gt;
        &lt;echo message="TESTING JAR COMPLETED."/&gt;
    &lt;/target&gt;
    
    &lt;!-- test the bin script --&gt;
    &lt;target name="mybintests" description="Test bin."&gt;
        &lt;chmod file="${test.script}" perm="ugo+rx"/&gt;
        &lt;echo message="Testing: sh -c ${test.script} ${dist.dir}"/&gt;
        &lt;exec executable="sh" failonerror="true"&gt;
            &lt;arg value="-c"/&gt;
            &lt;arg value="${test.script} ${dist.dir}"/&gt;
        &lt;/exec&gt;
        &lt;echo message="TESTING BIN SCRIPT COMPLETED."/&gt;
    &lt;/target&gt;
    
    &lt;!-- test the system script --&gt;
    &lt;target name="mysystemtest" description="Test system."&gt;
        &lt;chmod file="${test.system.script}" perm="ugo+rx"/&gt;
        &lt;echo message="Testing: sh -c ${test.system.script} ${dist.dir} ."/&gt;
        &lt;exec executable="sh" failonerror="true"&gt;
            &lt;arg value="-c"/&gt;
            &lt;arg value="${test.system.script} ${dist.dir} ."/&gt;
        &lt;/exec&gt;
        &lt;echo message="TESTING SYSTEM SCRIPT COMPLETED."/&gt;
    &lt;/target&gt;
    
    &lt;!-- findbugs target --&gt;
    &lt;target name="findbugs" depends="myfindbugs"
            description="Run findbugs in batch mode"/&gt;
    
    &lt;!-- my target that runs findbugs directly (in separate VM with 512M heap) --&gt;
    &lt;target name="myfindbugs" description="Run findbugs in batch mode"&gt;
        &lt;echo message="findbugs -maxHeap 512 -textui -effort:max -low -exitcode ${dist.jar}"/&gt;
        &lt;exec executable="findbugs" failonerror="true" vmlauncher="false"&gt;
            &lt;arg value="-maxHeap"/&gt;
            &lt;arg value="512"/&gt;
            &lt;arg value="-textui"/&gt;
            &lt;arg value="-effort:max"/&gt;
            &lt;arg value="-low"/&gt;
            &lt;arg value="-exitcode"/&gt;
            &lt;arg path="${dist.jar}"/&gt;
        &lt;/exec&gt;
        &lt;echo message="FINDBUGS COMPLETED."/&gt;
    &lt;/target&gt;
    
    &lt;!-- my own javadoc target because doc-files don't seem to get copied over --&gt;
    &lt;target name="myjavadoc" depends="init,-javadoc-build,-javadoc-browse" 
            description="Build Javadoc."&gt;
        &lt;mkdir dir="${doc.files}"/&gt;
        &lt;echo message="Populating doc-files directory: ${doc.files}"/&gt;
        &lt;copy todir="${doc.files}"&gt;
            &lt;fileset dir="${doc.files.src}" casesensitive="yes"&gt;
                &lt;include name="*"/&gt;
            &lt;/fileset&gt;
        &lt;/copy&gt;
        &lt;echo message="JAVADOC COMPLETED."/&gt;
    &lt;/target&gt;
    
    &lt;!-- all target --&gt;
    &lt;target name="all" depends="jar,test,mybintests,javadoc,findbugs"
            description="Do everything"/&gt;
    
</code>
</pre>
</li>
</ul>

<p>
<b><u>
So all the above is new and updated.
I could not get the echo to add a newline to the file, even following
all the documentation on echo, so I just used the exec target and the
echo command of the system.
I also had problems with javadoc populating the doc-files, so I
had to add my own doc-files copy. I'm not sure what I did
to break this. The javadoc command seemed to be sensitive to
relative vs. full paths, or the current directory setting.  

<p>
My recommendation again is to avoid the use of full paths
everywhere you can, it just makes life easier.
Also, any need to do simple shell commands like:
<br>
<code></u>
domainname | cut -d'.' -f2 | tr '[:upper:]' '[:lower:]'
</code><u>
<br>
had better be done in a shell script or in the Makefile.
In my real Makefile I do some system specific shell commands
to determine the value of an ant property that I pass into ant.
This works well for me because when running ant directly I don't
need this setting.
The other way to do this would be to exec a shell script and
capture it's output.
Running shell scripts in ant seems to work best when you
run them with <code>sh <i>command</i></code>.
Windows often will not recognize a shell script.
</u></b>

<p>
The findbugs task was not connected into the NetBeans
build/test system, and is just used by the Makefile or directly
from the ant script.

<p>
Well, it turns out that this works very nicely.

<p>
<b><u>
The following Makefile was updated to avoid the use
of full paths and simplify how the ant targets are used.
</u></b>

<p>
The Makefile was trivial, and looks like:

<ul>
<pre>
<code>
# Makefile to simulate a NetBeans build

# This Makefile is located one directory below the ant basedir
TOPDIR  = ..

# Value of ant property that needed to be created OS specific
system_instance=testsystem

# How to run ant
ANT_OPTIONS += -Djprt.system.instance=${system_instance}
ANT = ant $(ANT_OPTIONS)

# All ant targets of interest
ANT_TARGETS = all jar test javadoc findbugs clean init compile

# Create a make target for each
$(ANT_TARGETS):
        ( cd $(TOPDIR) && $(ANT) $@ )

# Declare these phony (not filenames)
.PHONY: $(ANT_TARGETS)

</pre>
</code>
</ul>

<p>
<b><u>
Update, now the path to ant and findbugs
 just need to be put in your PATH.
</u></b>

<p>
I'm sure there are better ways to do some of this, but I
did get the above working, and I am just an ant beginner.
I still don't see any easy way to loop over a set of names
with ant, and the 'condition' task is really confusing.
(No wonder there are 600+ page books on how to write ant scripts.)
I suppose people say the same thing about Makefiles. ;^)

<p>
Hope someone gets something out of this, and yes I've learned
to live with ants. ;^)

<p>
-kto]]>

</content>
</entry>
<entry>
<title>JDK6 Build Cheat Sheet</title>
<link rel="alternate" type="text/html" href="http://weblogs.java.net/blog/kellyohair/archive/2006/12/jdk6_build_chea.html" />
<modified>2008-02-13T18:05:20Z</modified>
<issued>2006-12-15T19:04:15Z</issued>
<id>tag:weblogs.java.net,2006:/blog/kellyohair/244.6182</id>
<created>2006-12-15T19:04:15Z</created>
<summary type="text/plain"> JDK6 Build Cheat Sheet Just thought I&apos;d list a few ways that the JDK can be built. These apply to JDK6 and JDK7, JDK5 building is a little different but has some of the same settings. The gnumake used...</summary>
<author>
<name>kellyohair</name>

<email>Kelly.Ohair@Sun.COM</email>
</author>
<dc:subject>Community: JDK</dc:subject>
<content type="text/html" mode="escaped" xml:lang="en" xml:base="http://weblogs.java.net/blog/kellyohair/">
<![CDATA[<html>
<body>

<h2> JDK6 Build Cheat Sheet </h2>

<p>
Just thought I'd list a few ways that the JDK can be built.
These apply to JDK6 and JDK7, JDK5 building is a little different
but has some of the same settings.
The <code>gnumake</code> used here is the GNU make 3.78.1 or newer.

<ul>
<li>
On Solaris systems with the Companion CD installed, it can 
usually be found
with the name <code>gmake</code> in <code>/usr/sfw/bin/</code> or
<code>/opt/sfw/bin/</code>.
</li>
<li>
On Linux just use <code>make</code> from <code>/usr/bin/</code>
</li>
<li>
On Windows and using CYGWIN, just use <code>make</code> from CYGWIN's
<code>/usr/bin/</code>
(but make sure it's not 3.81, which seems to have taken away the ability
to use paths with the ':' character, like <code>C:/anything</code>.)
</li>
<li>
On Windows with MKS, you will need a GNU make built for MKS.
</li>
</ul>

<p>
See 
<a href=http://download.java.net/jdk6/6u1/promoted/b01/docs/build/README-builds.html#gnumake>
the JDK build instructions for more information.</a>
<br>
<B>NOTE:</b> Any variables described below that start with
<code>ALT_</code> can be set on the <code>gnumake</code>
command line, or be set in your environment. None of the Makefiles
should be setting these variables internally, so no internal
make variable setting should change your environment variable
setting of them. The command line variable settings will override
any setting inside the Makefiles.


<h3> Control Builds </h3>

<p>
From the control/make/Makefile:

<ul>

<li>
Build everything for a developer:
<p>
<code>gnumake dev</code>
<br> OR <br>
<code>gnumake DEV_ONLY=true</code>
</li>

<li>
Skip the fastdebug build (just builds the product bits):
<p>
<code>gnumake SKIP_FASTDEBUG_BUILD=true DEV_ONLY=true</code>
</li>

<li>
Don't build the fastdebug bits, and skip the hotspot and deploy areas:
<p>
<code>gnumake BUILD_HOTSPOT=false BUILD_DEPLOY=false ALT_JDK_IMPORT=/jdk1.6.0 SKIP_FASTDEBUG_BUILD=true DEV_ONLY=true</code>
</li>

<li>
Build just the j2se debug image:
<p>
<code>gnumake BUILD_HOTSPOT=false BUILD_DEPLOY=false ALT_JDK_IMPORT=/jdk1.6.0 SKIP_FASTDEBUG_BUILD=true SKIP_DEBUG_BUILD=false DEV_ONLY=true debug_build</code>
</li>

</ul>

<p>
Here is a short list of the make variables that can be set on the
<code>gnumake</code> command line:

<ul>

<li>
<code>BUILD_HOTSPOT</code>
<p>
Set to <code>false</code> to avoid building the hotspot VM, but you will
need to also set <code>ALT_JDK_IMPORT_PATH</code> to a built jdk
product of the same version you are building.
I recommend setting this to <code>false</code>
all the time, unless you are changing the hotspot VM.
</li>

<li>
<code>BUILD_DEPLOY</code>
<p>
Set to <code>false</code> to avoid building javaws or the plugins.
I recommend setting this to <code>false</code> all the time.
</li>

<li>
<code>BUILD_INSTALL</code>
<p>
Set to <code>false</code> to avoid building install bundles
(you should never need to do this).
I recommend setting this to <code>false</code> all the time.
</li>

<li>
<code>BUILD_J2SE</code>
<p>
Set to <code>false</code> to avoid the core j2se, which is unlikely
you'd want to do this. I'd leave this one alone, unless you are
only working on the hotspot VM.
</li>

<li>
<code>BUILD_MOTIF</code>
<p>
Set to <code>false</code> to avoid building the Motif libraries,
but you would need to then set
<code>ALT_MOTIF_DIR</code> to where to get the built Motif libraries.
This doesn't take long to build so I have never played with this,
and I'm not even sure it's necessary
</li>

<li>
<code>NO_DOCS</code>
<p>
Set to <code>true</code> to avoid any javadoc generation.
</li>

<li>
<code>NO_IMAGES</code>
<p>
Set to <code>true</code> to avoid any images generation.
This means the creation of the more formal JDK install-like image
with the rt.jar and tools.jar files.
When the images are not built, the JDK is left in the
<code>OUTPUTDIR</code> area as a simple set of <code>bin</code>,
<code>lib</code>, <code>include</code>, and <code>classes</code>
directories. Which can be run as-is, but do not represent the
form that a JDK install image will take.
The creation of the images is mostly a disk movement activity, and
on some machines this is very fast, and with others it can be slow.
</li>


<li>
<code>SKIP_FASTDEBUG_BUILD</code>
<p>
Set to <code>true</code> to skip building any fastdebug bits
(a set of -g -O built images with full runtime assert checking enabled).
</li>

<li>
<code>SKIP_DEBUG_BUILD</code>
<p>
Set to <code>false</code> to build the debug images (-g with full 
runtime assert checking).
</li>

<li>
<code>DEV_ONLY</code>
<p>
Set to <code>true</code> to get the settings:
<code>SKIP_COMPARE_IMAGES=true BUILD_INSTALL=false NO_DOCS=true</code>.
</li>

<li>
<code>SKIP_COMPARE_IMAGES</code>
<p>
Set to <code>true</code> to avoid a comparison of previous release
build bundles with the ones you have created.
You normally won't want this, so always set this to <code>true</code>.
</li>

<li>
<code>ALT_OUTPUTDIR</code>
<p>
Alternative output directory rather than 
<code>control/build</code>.
I recommend that the sources and this output directory be on your
build machines local disk, for best build time performance.
</li>

<li>
<code>ALT_BOOTDIR</code>
<p>
Alternative location for a bootstrap JDK, or install image of the
previously released JDK (e.g. jdk1.5.0 for building jdk1.6.0).
You really should set this all the time, just to make sure you get a
local disk copy, for best build time performance.
In theory, this doesn't have to be jak1.5.0, but could be a
newer JDK, even the same version being built. But normally
it's the previously release JDK.
</li>

<li>
<code>ALT_JDK_IMPORT_PATH</code>
<p>
Alternative location for a JDK build of the same release as what
you are building. 
If you skip building some components, the Makefiles will try and
copy over the pre-built bits from this location, e.g.
if you use BUILD_HOTSPOT=false (or don't have a <code>hotspot</code>
directory), then the hotspot built images will be copied from this
location.
</li>

</ul>

<p>
Also try running <code>gnumake help</code> for more help
on building options.

<h3> J2SE Builds </h3>

<p>
If you only want to work with the j2se and not the VM, you might
consider just going into the <code>j2se/make</code> directory
and running <code>gnumake</code> from there.
Just run <code>gnumake help</code> for some help.

<p>
I'd recommend setting <code>ALT_BOOTDIR</code> and
<code>ALT_JDK_IMPORT_DIR</code> (as described above).

<h3> Hotspot Builds </h3>

<p>
If you only want to work with the hotspot and not the VM, you might
consider just going into the <code>hotspot/make</code> directory
and running <code>gnumake</code> from there.
Just run <code>gnumake help</code> for some help.

<p>
I'd recommend setting <code>ALT_BOOTDIR</code> and
<code>ALT_JDK_IMPORT_DIR</code> (as described above).

<p>
Traditionally the hotspot build procedure have differed greatly
from the rest of the JDK. This is mostly
due to the fact that for the most part, it's more like building
a large C++ library rather than anything else.
Building each of the platforms was slightly different,
for example on Windows the tool <code>NMAKE.EXE</code>
was used instead of <code>gnumake</code>.
It's the Makefiles and build scripts in the hotspot/build
directory that contain the "real" hotspot build procedures.
In JDK6 a <code>gnumake</code> Makefile was added at
<code>hotspot/make/Makefile</code> which will use the Makefiles
in the <code>hotspot/build</code> area, providing you a more
generic hotspot building experience.
More experienced hotspot builders may prefer to dive into
the <code>hotspot/build</code> area.

<h3> Summary </h3>

<p>
So as you can see, some similarities, some differences between
these build rules.

<p>
Hope this was helpful, if you have more questions please post comments.

<p>
-kto

</body>
</html>

]]>

</content>
</entry>

</feed>