The future of OpenJDK6

[Joe Darcy]

Responding to one point below,

On 3/13/2013 12:47 PM, Andrew Hughes wrote:
> ----- Original Message -----

[snip]

> 4. Finally, this is just a thought, and I realise it may run contrary 
> to your promise of long-term stability and compatibility, but I've 
> been giving some thought to the long running issues we've had with 
> javac in OpenJDK 6.


What concrete issues with OpenJDK 6 javac are you referring to? Are 
there bugs for them?

> For those who are unaware, the javac in OpenJDK 6 is not the same as 
> in Oracle's proprietary JDK 6, but rather an early development version 
> of the one used in OpenJDK 7.

The above is an incorrect categorization of the javac in OpenJDK 6 and 
more broadly the langtools repository in OpenJDK 6.

All of OpenJDK 6 initially branched off of (Open)JDK 7 build 20 or so. 
There were fixes in javac and more broadly langtools at that time 
compared to JDK 6 GA. Those fixes were largely appropriate to a Java SE 
6 comiler and therefore kept in; inappropriate changes were backed out. 
At least during the 3+ year tenure when I was release manager of OpenJDK 
6, the langtools team made sure that all javac fixes that went into the 
Sun/Oracle proprietary JDK 6 also went into OpenJDK 6. Therefore, the 
OpenJDK 6 javac has had a strict superset of the fixes in Sun/Oracle JDK 
6. The compilers in both OpenJDK 6 and JDK 6 pass the relevant JCK tests.

The OpenJDK 6 javac and JDK 6 javac are different, but I would argue the 
OpenJDK 6 javac was and is better.

The differences between the OpenJDK 6 and JDK 6 versions of other 
components vary by repository and area. As you noted, for some time 
RedHat has kept the hotspot repo of OpenJDK 6 generally in sync with the 
stabilized HotSpot express releases. At least times in the past, the 
jaxp, jaxws, and cobra OpenJDK 6 repos have been functionally identical 
to their JDK 6 counterparts. Some of this is detailed in an old blog post:

     "OpenJDK 6: Logistics of Partial Merge with 6u10"
https://blogs.oracle.com/darcy/entry/openjdk_6_logistics_of_partial

That leaves the "jdk" repo where most of the core libraries live 
(java.lang, java.util, java.awt, etc.). There has never been an 
analagous grand merge between what would logically be the jdk repo of 
the JDK 6 train and the jdk repo of OpenJDK 6. However, this has not 
seemed to be too much of an impediment to usability or to backporting 
security patches and other fixes as needed.

> I've been wondering if the best way of supporting this long-term would 
> be to use the tools from 7 in OpenJDK 6, with appropriate reversions 
> to make it compatible with 6 (defaulting to 6 source/target, having 
> builds pass the 6 TCK), rather than continuing to maintain the hybrid 
> we have now. This would also mean we'd be able to benefit more 
> directly from any bug fixes or security updates directed at the 
> langtools present in 7. In closing, I'd like to welcome this new 
> chapter in the life of OpenJDK 6 and I hope it is successful in 
> continuing existing community involvement, and hopefully taking things 
> even further. Thanks, 

The code in the (Open)JDK 7 uses the Java SE 7 versions of the 
javax.lang.model.* API, which differ from the Java SE 6 versions. It 
would be a "small matter of programming" to adjust the rest of the javac 
sources accordingly. Note that some portions of the langtools repo in 
OpenJDK 7 outside of parts involved in bootstrapping may rely on Java SE 
7 APIs.

Whether or not undertaking this exercise would lead to lower long-term 
maintenance costs I cannot say, but it is not clear to me that it would.

-Joe