OpenJDK 6 Processes
Andrew John Hughes
ahughes at redhat.com
Thu Mar 25 16:28:08 PDT 2010
On 25 March 2010 23:21, Jonathan Gibbons <Jonathan.Gibbons at sun.com> wrote:
> Joseph D. Darcy wrote:
>> 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 b06. 
>> 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
>> 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 individual
>> 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:
>> 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?
>> -Joe Darcy
>> 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,"
>>  http://hg.openjdk.java.net/hsx/hsx14/master
>>  http://hg.openjdk.java.net/hsx/hsx16/master
>>  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.
>>  http://icedtea.classpath.org/wiki/Main_Page
> You might consider posting these processes on the OpenJDK 6 project page
> here: http://openjdk.java.net/projects/jdk6/
> -- Jon
Yes, I was sort of presuming they would be posted somewhere... and
there seems a good place. +1.
Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)
Support Free Java!
Contribute to GNU Classpath and the OpenJDK
PGP Key: 94EFD9D8 (http://subkeys.pgp.net)
Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8
More information about the jdk6-dev