java tech related xiomara

Since build 66 was a milestone release the bundles are now available at java.sun.com. 

I would also like to note that my previous blog entry mentioned that all  planned features for Milestone 4 got in -- turns out that the XML stack, which includes jaxp, jaxb and jax-ws APIs, did not get in.  The work for that feature is in progress.

JDK 7 build 66 which is the final build for Milestone 4 has been released!

The last milestone (M3) was released during the JavaOne time frame and since then, the teams have been making progress by fixing bugs and forward porting changes from the other JDK trains to JDK7.

The forward port work was from the JDK 6u10 through 6u14 trains.  For now JDK 7 is finally in sync with the JDK 6u14 updates.  Some of the features in the forward port included: The new Java Plug-In, Java Kernel, Quickstarter, Patch-in-place, Deployment Toolkit and related installer features.  A write up of some of those features is found here. The entire set of planned features can be found in the JDK 7 features list. 

The source for the mentioned features mostly went into the closed JDK 7 mercurial repositories but the binaries do comprise all that work.  Some of the features slated for M4 actually went into M3, such as the Swing Nimbus look-and-feel, everything else planned for M4 went in as supposed to.

The list of bug fixes that made it into this milestone is outlined in each of the build summaries and includes: 

http://download.java.net/jdk7/changes/jdk7-b60.html, jdk7-b61.html, jdk7-b62.html, through jdk7-b66.html.

The source for this Milestone can be pull from the JDK 7 repositories at: http://hg.openjdk.java.net/jdk7/jdk7 by using the jdk7-b66 tags, as I described in previous posts.

Onto Milestone 5, which will be released sometime in the beginning of September 09. 

JDK 7 Milestone 3 has been released!  Build 59 was the sixth and final build for Milestone 3.

Along with code changes that went into Milestone 3 which are summarized here: http://download.java.net/jdk7/changes/jdk7-b59.html, Milestone 3 included changes to the JDK 7 documentation, which had been on hiatus for several builds.  The changes to the docs can be found here: http://download.java.net/jdk7/docs/.

Development for Milestone 4 continues and we expect for it to complete towards the end of July. 

The source for b59 can be downloaded any time, from the Mercurial Repositories by doing the following:

hg fclone -r jdk7-b59 http://hg.openjdk.java.net/jdk7/jdk7 myjdk7

Prior to build 54, the official Linux builds for OpenJDK7 and JDK 7 were built on Red Hat 2.1 Advanced Server (32 bit) and SUSE 8 (64 bit). Starting with b54, Release Engineering will use Fedora 9 for both the 32 and 64 bit builds. Building on Fedora 9 required some changes to the build scripts and makefiles and those changes were pushed in previous builds (some as far back as October 2008) to enable testing on the bits prior to doing the complete switch to Fedora 9.

From b54, builds will run on most Linux distributions and will build on them as well. Some sanity testing was done on popular OSs such as:
RH 5.0 through 5.3
SLES 11 +
Ubuntu 8.04, Ubuntu 8.10
These OSs were chosen for a variety of reasons, one of which was the need for an RPM-based packaging system.

The following link to the build README for OpenJDK 7 explains how to setup your build system with Fedora and how to go about doing a build:
http://hg.openjdk.java.net/jdk7/jdk7/raw-file/tip/README-builds.html#fedora

The list of changes for build 54 can be located here:
http://download.java.net/jdk7/changes/jdk7-b54.html

In other news, Binary Bundles for JDK7 (note, not OpenJDK7) are now available on a daily basis at http://download.java.net/jdk7/nightly!

I pushed build 53 (b53) to download.java.net yesterday.

Build 53 is the fifth and final build for Milestone 2 of OpenJDK7: Schedule Overview.

Milestone 3 is the JavaOne Preview, and we will do seven builds (b54-b60) to reach it.

Some of the integration areas pushed into the master during b53 (Integration Schedule) were: Tools and Libraries (TL), Hotspot and Build. (Other integration areas, such as Swing and Jaxp, chose not to use their integration slots during b53.) One notable feature from TL was the Reference Implementation for JSR 203. Here are some of the smaller changes from TL:

6810254: Register the shutdown hooks only when needed and remove JavaIODeleteOnExitAccess 
(instantiating the shared secret access objects)
6786688: Javadoc HTML WCAG 2.0 accessibility issues in standard doclet - Table must have 
captions and headers
6661448: Make the SNMP agent optional when OPENJDK=true and IMPORT_BINARY_PLUGS=false
6695776: Forward port of changes from the 6-open train.

As well as JSR 203, the big news in b53 is that the binary plugs are no longer needed to be able to build OpenJDK! Some of the changesets that enable this are 964cc8eb3232,  ecb7723aaa7c, and a2033addca67.   Thanks to Tim and Kelly.

One of the changes pushed (Changesets 964cc8eb3232 for BugID: 6819847) broke the OpenJDK build.
If you run into errors because you are still trying to use the binary plugs to build the OpenJDK, then remove all references to ALT_BINARY_PLUGS_PATH in your setup, since you no longer need the binary plugs.

Hotspot also integrated their fixes into b53 and some of their changes included:

6812297: update project creation for Visual Studio 2005-2008

The complete list of changes for b53 can be found at the OpenJDK download website here. For this build I will be using a new format for the Summary of Changes than the one used in previous builds.  The new Summary of Changes will be created from the Mercurial repositories, and will contain links to bugs and the changesets where those bugs were fixed.

 Thanks again, to my editor ;-)

The goal of Java Release Engineering is a reliable, reproducible and consistent build process. 

If you are not familiar with Mercurial repositories and forests, please see understanding mercurial.

The following is a representation of the build process for JDK7:

• Remember: There is only one set of source for the OpenJDK and the regular JDK!
  
  
• Integration areas: Each team has its own integration area: 2d, awt, hotspot, tl, jaxws, build, etc. An integration area is a forest which contains six repositories: corba, hotspot, jaxp, jaxws, jdk, langtools.  Together, these six repositories contain almost the entire JDK source. This allows a team to make all the changes necessary for its features regardless of where in the source they occur.
  
  
• Each integration area is associated with a gate. A gate is a forest which is simply a copy of the integration area. A team pushes changes into the gate for their area, and the gate synchronizes with the area automatically. Each area has a gatekeeper who builds it to ensure the team's code does not break the overall JDK build.
  
  
• Master: There is a master forest where the "official" source resides. You can see the list of JDK7 forests here - the master is jdk7/jdk7 and its child repositories are jdk7/jdk7/corba, jdk7/jdk7/hotspot, etc. The master's gate is jdk7/jdk7-gate and its child repositories are jdk7/jdk7-gate/corba, jdk7/jdk7-gate/hotspot, etc.
  
  
• You can jump to a forest directly by appending its name to http://hg.openjdk.java.net/, e.g. the master jdk7/jdk7 is located at http://hg.openjdk.java.net/jdk7/jdk7.
  
  
• The source of the master is also available for convenience in a ZIP file at this location.
  

• The gatekeeper of an integration area is responsible for pushing the area's changes to the master's gate during the area's scheduled integration slot. The master's gate synchronizes with the master automatically, just as the integration areas synchronize with their gates automatically.
  
  
• The following diagram shows the master and gate for the 'open' part of the JDK. The 'closed' master and gate are not shown - they contain a very minor portion of the JDK source which is still encumbered.
  
  

• Release Engineering pulls build changes on a nightly or daily basis from the open and closed masters.  Nightly builds are run for eight different platforms as shown below in the blue boxes.

• The promotion process happens weekly on a schedule. Promotion follows the same steps as the nightly build process except for the grayed out boxes above. It additionally distributes the built bits to QA teams in Sun to run acceptance testing. After QA has accepted the binaries, they are posted on the web for the JDK7 and OpenJDK7.
  

• To summarize, the overall build process is shown below:
  
  

 Many thanks to Alex Buckley for his help with this blog entry!

I am a release engineer in the Java organization. I am responsible for the build process for JDK7 (including OpenJDK7) and the Java Compatibility Kit, and work with Kelly O'Hair, Tim Bell, Mark Reinhold and other members of the JDK team to produce reliable and consistent builds.

I will use this blog mostly for Java-related entries pertaining to the JDK. I will post things that I find useful for the build and will also add news regarding releases.