The future of OpenJDK6

[Andrew Hughes]

----- Original Message -----
> Removing discuss at openjdk.java.net from the distribution list.
> 
> 
> On 3/13/2013 8:25 PM, Martin Buchholz wrote:
> 
> 
> 
> Our experience at Google has been that javac7 is a stricter compiler
> than javac6. It is a significant effort migrating from javac6 to
> javac7 with a large code base. Since openjdk6 is all about
> stability, I would resist updating the javac in openjdk6. Some of
> the "bugs" in javac6 allow user code to compile successfully!
> The command
> 
> $JDK7/bin/javac -source 6 -target 6 -bootclasspath $JDK7-RT.JAR
> <args>
> 
> should be a fine Java SE 6 compiler, but I'm not surprised Martin and
> company have found that it is stricter than the compilers shipped in
> JDK 6, besides the Project Coin features, lots of fixes went into
> JDK 7 too. If one can abide the stricter checks, the JDK 7 series
> compiler offers much improved error messages in some cases.
> 
> For the consideration of the current managers of OpenJDK 6, I've gone
> through the JDK bug database and found bug fixes applied to the JDK
> 7/7 update and 6 update trains but *not* to OpenJDK 6; the list is
> below. (These fixes date from after my time as OpenJDK 6 release
> manager; I stepped down in February 2011 and 6u27 was released in
> August 2011.)
> 
> 6u27 JDK-6718364 inference fails when a generic method is invoked
> with raw arguments
> http://hg.openjdk.java.net/jdk7u/jdk7u/langtools/rev/30a415f8667f
> 
> 6u30 JDK-6682380 Foreach loop with generics inside finally block
> crashes javac with -target 1.5
> http://hg.openjdk.java.net/jdk7u/jdk7u/langtools/rev/ec29a1a284ca
> 
> 6u30 JDK-7046929 tools/javac/api/T6397104.java fails
> http://hg.openjdk.java.net/jdk7u/jdk7u/langtools/rev/592c30109bbe
> 
> 6u30 JDK-7024568 Very long method resolution causing OOM error
> http://hg.openjdk.java.net/jdk7u/jdk7u/langtools/rev/74f0c05c51eb
> 
> 6u32 JDK-7003595 IncompatibleClassChangeError with unreferenced local
> class with subclass
> http://hg.openjdk.java.net/jdk7u/jdk7u/langtools/rev/41a303cb946e
> 
> 6u34 JDK-6500343 compiler generates bad code when translating
> conditional expressions
> http://hg.openjdk.java.net/jdk7u/jdk7u/langtools/rev/ddd110646d21
> 

Many thanks Joe!!! This is excellent.

> Cheers,
> 
> -Joe
> 
> 
> 
> 
> 
> 
> 
> On Wed, Mar 13, 2013 at 1:47 PM, Jonathan Gibbons <
> jonathan.gibbons at oracle.com > wrote:
> 
> 
> 
> On 03/13/2013 12:47 PM, Andrew Hughes wrote:
> 
> 
> 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. 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.
> 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.
> 
> You might want to bring this up on compiler-dev.
> 
> -- Jon
> 
> 
> 

-- 
Andrew :)

Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

PGP Key: 248BDC07 (https://keys.indymedia.org/)
Fingerprint = EC5A 1F5E C0AD 1D15 8F1F  8F91 3B96 A578 248B DC07