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
