The future of OpenJDK6

[Joe Darcy]

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

Cheers,

-Joe

>
>
> On Wed, Mar 13, 2013 at 1:47 PM, Jonathan Gibbons 
> <jonathan.gibbons at oracle.com <mailto: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
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20130313/50436501/attachment.html