OpenJDK 6 Processes
Joseph D. Darcy
Joe.Darcy at Sun.COM
Thu Mar 25 15:58:54 PDT 2010
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.  One example of such an
API change was the upgrade of JAX-WS from 2.0 to 2.1 in OpenJDK 6 build
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.   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  or HotSpot Express 16 ) are suitable
for bulk porting to the OpenJDK 6 HotSpot forest without review of
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
The master Mercurial forest of OpenJDK 6 repositories resides at:
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. 
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 , 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?
OpenJDK 6 Release Manager
 "Java Endorsed Standards Override Mechanism",
 "OpenJDK 6: Sources for b06 Published,"
 "Kinds of Compatibility: Source, Binary, and Behavioral,"
 "JDK Release Types and Compatibility Regions,"
 Alternatively, in JDK 7 there are a hierarchy of staging integration
forests under the master to manage a higher rate of change (see "OpenJDK
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.
More information about the jdk6-dev