Kelly O'Hair's Weblog (blogs.sun.com)
Wednesday Aug 12, 2009
Anatomy of the JDK Build
The recent "javac -target 7" changes to the jdk7 repositories has prompted me to post this blog about OpenJDK builds. To those unfamiliar with Java classfile versions, each JDK release typically has upgraded the version of the classfiles created by the javac compiler, newer JDKs understand it's own classfile version, plus all the older versions. But older JDKs can NOT understand the newer classfile versions, and their javac instances will not understand how to create newer versions, which of course, makes perfect sense, not sure why I had to say that... oh well... The JDK itself usually contains the newest classfile version, however JDK6 delivered JDK5 classfiles. With JDK7 we want to deliver the latest classfile version in the JDK itself, so the way the JDK is built becomes more interesting to know.
See Alex's version blog, Joe's version blog, and Joe's build advice blog for more information.
When building the OpenJDK from scratch, there are 7 repositories involved, many different system components used in the build process, and an ordering or dependency chain.
For now I'll ignore the build variations or flavors of builds, such as product (optimized), fastdebug, and debug, which generally just repeat the same steps but with slight variations on how the bits are built. What I wanted to do here was describe the dependencies between the repositories and the bootstrap jdk used in the build.
Granted this could change, but currently building OpenJDK JDK7 sources from scratch happens in this order:
- The langtools repository (repository that holds javac, javah, etc.) is built first using the bootstrap jdk6 javac. This creates a bootstrap javac.jar compiler that can be run with the bootstrap jdk. This bootstrap javac.jar is capable of compiling and creating the newer jdk7 source and classfiles, e.g. it understand -target 7 and -source 7.
Note that the langtools sources need to be jdk6 compiled sources, and when this repository is built, it also uses the bootstrap javac.jar to compile itself into -target 7 classfiles to be put into the final jdk7 image. Keep in mind that we cannot run jdk7 classfiles yet, we can create them using the bootstrap jdk and the bootstrap javac.jar, but we have no jdk7 image to run yet.
- The corba repository is built using the bootstrap jdk and the bootstrap javac.jar from the langtools build.
- The jaxp repository is built using the bootstrap jdk and the bootstrap javac.jar from the langtools build.
- The jaxws repository is built using the bootstrap jdk and the bootstrap javac.jar from the langtools build.
Note that up to this point, these are jdk7 classes, but built with a jdk6 runtime (the jdk6 rt.jar classes). The jdk7 rt.jar has not been built yet. This has not been an issue in that the sources in corba, jaxp, and jaxws are restricted to jdk6 interfaces and have no need for jdk7 specific interfaces. This is also why a jdk5 cannot be used as the bootstrap jdk, jdk5 does not have all the interfaces needed by the above repositories.
- The hotspot repository is built using the native C++ compiler.
Note that hotspot includes java source, however that source is currently compiled with the bootstrap jdk javac, not the langtools bootstrap javac.jar. This may need to change in the future, but there may be some requirements for using -target 6 or even -target 5 with whatever javac is used here.
- Lastly the jdk repository is built. This repository pulls all the above builds together, and also builds the rest of the jdk using the bootstrap jdk and the langtools bootstrap javac.jar. The actual javac included in the jdk7 image will have been the -target 7 built classes. Eventually it will have created enough of a jdk7 image that it could be run on it's own, at that point the demos are built and the image is finalized.
Note that when building these jdk sources, they are built in a particular order defined by the Makefiles, and against themselves, so that in a sense, these classes are compiled against what will become the jdk7 runtime.
A really good test at this point is to use this newly built jdk7 as the bootstrap jdk, and build a second jdk7. It should work. The top level Makefile has an option to do this make SKIP_BOOT_CYCLE=false.
You can build each repository separately and most developers do, but now that we have this -target 7 requirement, you may need to specify the bootstrap jdk as jdk7, include the langtools repository as part of your build, or set ALT_LANGTOOLS_DIST to point to the langtools/dist directory (a built langtools repository).
Hope this helps to explain things a little. Please post any questions you have, I'll try and answer all I can. And hopefully Jonathan will keep me honest here. :^)
-kto
Posted at 12:21PM Aug 12, 2009 by kto in Java | Comments[6]












Good (and welcome) summary, Kelly. Some minor additional points come to mind.
1. As well as a bootstrap javac, the langtools repository delivers bootstrap versions of javah and javadoc to be used during the rest of the build.
2. The bootstrap javac is also used to build small utility programs that will be used during the build itself.
3. Some of the repositories use Ant for their primary build system, with a Makefile wrapper. Some of those Ant builds create Ant tasks to be used by Ant during the build. These tasks are normally built by the version of javac "provided" by Ant.
Posted by Jonathan Gibbons on August 21, 2009 at 04:55 PM PDT #
Lately I've seen quite many pros have trouble with their Windows JDK installations. Would it be too much of a hassle to offer just a ZIP file of each JDK version in addition to the EXE installer?
Posted by Mikael Gueck on August 22, 2009 at 09:55 AM PDT #
A plain zip file doesn't provide the kind of agreement acceptance that our legal needs. On Solaris and Linux we provide self-extracting tar-balls that ask people to accept the license terms before exploding the bundle. I know everybody reads them in detail. ;^) But on Windows, creating a self extracting bundle is hard to do, and if it isn't a simple download and explode, something that can be automated, I'm not sure that helps.
The best hope is for a simple OpenJDK zip bundle, but we currently don't provide builds of OpenJDK, yet.
-kto
Posted by Kelly Ohair on August 24, 2009 at 11:06 AM PDT #
Since the Oracle legal department doesn't seem to have problems with providing downloadable tarballs, maybe this will change shortly.
I'll keep an eye on the OpenJDK situation, thanks for the tip.
Posted by Mikael Gueck on August 24, 2009 at 06:18 PM PDT #
Mikael, as Kelly says, the problem is not with producing tarballs, but that Sun don't produce builds of OpenJDK to begin with. Your comparison with Oracle tarballs is unclear, as you don't provide an example, but I would assume you are not comparing like with like. Oracle will have to provide a End User License Agreement (EULA) to its users for the current proprietary builds just as Sun does.
Posted by Andrew John Hughes on August 26, 2009 at 06:45 AM PDT #
Exactly right Andrew, thanks.
-kto
Posted by 192.18.43.225 on August 26, 2009 at 01:48 PM PDT #