OpenJDK 6 Processes

[Joseph D. Darcy]

Since questions about OpenJDK 6 processes come up from time to time, I 
thought it would be helpful to more fully document the current 
engineering practices and receive comments about them on the list.

OpenJDK 6 is an implementation of the Java SE 6 specification valuing 
stability, compatibility, and security.  As an implementation of the 
Java SE 6 specification, all changes to OpenJDK 6 must be allowable 
within that specification.  This requirement precludes many API 
changes.  Acceptable API changes include those permitted by the endorsed 
standards mechanism, such as upgrading to a newer version of a 
standalone technology, like a component JSR. [1]  One example of such an 
API change was the upgrade of JAX-WS from 2.0 to 2.1 in OpenJDK 6 build 
b06. [2]

Changes allowable within the Java SE 6 specification may still be 
rejected for inclusion in OpenJDK 6 if the *behavioral compatibility* 
risk is judged as too large. [3] [4]  Behavioral compatibility concerns 
implementation properties of the JDK.  Clients of the JDK can knowingly 
or unknowingly come to rely upon implementation-specification behaviors 
not guaranteed by the specification and care should be taken to not 
break such applications needlessly.  In contrast, if a change is 
appropriate for every other JDK release train, it is generally 
appropriate for OpenJDK 6 too.  Examples of such universal changes 
include security fixes and time zone information updates.

With the above caveats, bug fixes in JDK 7 that do not involve 
specification changes have presumptive validity for OpenJDK 6.  That is, 
by default such fixes are assumed to be applicable to OpenJDK 6, 
especially if having "soaked" in JDK 7 for a time without incident.  On 
a related point, the fixes from the stabilized HotSpot forests (for
example HotSpot Express 14 [5] or HotSpot Express 16 [6]) are suitable 
for bulk porting to the OpenJDK 6 HotSpot forest without review of 
individual bugs.

As a general guideline, if a change is applicable to both JDK 7 and 
OpenJDK 6, the change should be made in JDK 7 no later than the change 
is made in OpenJDK 6.

With the exception of security fixes, all OpenJDK 6 code review traffic 
should be sent to jdk6-dev at openjdk.java.net for consideration before a 
commit occurs.  (For subscription instructions and to browse the 
archives see http://mail.openjdk.java.net/mailman/listinfo/jdk6-dev)  
All fixes require the approval of the release manager and may require 
additional technical review and approval at the discretion of the 
release manager.  Security fixes are first kept confidential and applied 
to a private forest before being pushed to the public forest as part of 
the general synchronized publication of the fix to effected JDK release 
trains.

The master Mercurial forest of OpenJDK 6 repositories resides at:
http://hg.openjdk.java.net/jdk6/jdk6

Since there is only a single master OpenJDK 6 forest, near the end of a 
build period the release manager may defer otherwise acceptable changes 
to the start of the next build. [7]

The schedule to tag builds of OpenJDK 6 is on an as-needed basis.  The 
timing and feature list of a build is coordinated on the jdk6-dev alias 
with the IcedTea 6 project [8], a downstream client of OpenJDK 6.  
Before a build is tagged, regression and other testing is performed to 
verify the quality of the build.

Comments on any of the above?

-Joe Darcy
OpenJDK 6 Release Manager

------

[1] "Java Endorsed Standards Override Mechanism",
http://java.sun.com/javase/6/docs/technotes/guides/standards/

[2] "OpenJDK 6: Sources for b06 Published,"
http://blogs.sun.com/darcy/entry/openjdk_6_sources_for_b06

[3] "Kinds of Compatibility: Source, Binary, and Behavioral,"
http://blogs.sun.com/darcy/entry/kinds_of_compatibility

[4] "JDK Release Types and Compatibility Regions,"
http://blogs.sun.com/darcy/entry/release_types_compatibility_regions

[5] http://hg.openjdk.java.net/hsx/hsx14/master

[6] http://hg.openjdk.java.net/hsx/hsx16/master

[7] Alternatively, in JDK 7 there are a hierarchy of staging integration 
forests under the master to manage a higher rate of change (see "OpenJDK 
Mercurial Wheel",
http://blogs.sun.com/kto/entry/openjdk_mercurial_wheel).  As the rate of 
change in OpenJDK 6 is comparatively small, as long as the end of build 
quiet periods continue to be acceptably short, having a single master 
forest should be simpler than starting and managing an intermediate 
staging forest kept open to accepting changes at all times.

[8] http://icedtea.classpath.org/wiki/Main_Page