Removing disc...@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.gibb...@oracle.com <mailto:jonathan.gibb...@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
