<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
Removing <a class="moz-txt-link-abbreviated" href="mailto:discuss@openjdk.java.net">discuss@openjdk.java.net</a> from the distribution list.<br>
<br>
<div class="moz-cite-prefix">On 3/13/2013 8:25 PM, Martin Buchholz
wrote:<br>
</div>
<blockquote
cite="mid:CA+kOe0_vmpFxot2QADQLDBsUBHPLafoOPF79tx2Spg-Z1m9v8A@mail.gmail.com"
type="cite">
<div dir="ltr">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!</div>
</blockquote>
<br>
The command<br>
<br>
$JDK7/bin/javac -source 6 -target 6 -bootclasspath $JDK7-RT.JAR
<args><br>
<br>
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.<br>
<br>
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.)<br>
<br>
6u27 JDK-6718364 inference fails when a generic method is
invoked with raw arguments<br>
<a class="moz-txt-link-freetext" href="http://hg.openjdk.java.net/jdk7u/jdk7u/langtools/rev/30a415f8667f">http://hg.openjdk.java.net/jdk7u/jdk7u/langtools/rev/30a415f8667f</a><br>
<br>
6u30 JDK-6682380 Foreach loop with generics inside finally block
crashes javac with -target 1.5<br>
<a class="moz-txt-link-freetext" href="http://hg.openjdk.java.net/jdk7u/jdk7u/langtools/rev/ec29a1a284ca">http://hg.openjdk.java.net/jdk7u/jdk7u/langtools/rev/ec29a1a284ca</a><br>
<br>
6u30 JDK-7046929 tools/javac/api/T6397104.java fails<br>
<a class="moz-txt-link-freetext" href="http://hg.openjdk.java.net/jdk7u/jdk7u/langtools/rev/592c30109bbe">http://hg.openjdk.java.net/jdk7u/jdk7u/langtools/rev/592c30109bbe</a><br>
<br>
6u30 JDK-7024568 Very long method resolution causing OOM error<br>
<a class="moz-txt-link-freetext" href="http://hg.openjdk.java.net/jdk7u/jdk7u/langtools/rev/74f0c05c51eb">http://hg.openjdk.java.net/jdk7u/jdk7u/langtools/rev/74f0c05c51eb</a><br>
<br>
6u32 JDK-7003595 IncompatibleClassChangeError with unreferenced
local class with subclass<br>
<a class="moz-txt-link-freetext" href="http://hg.openjdk.java.net/jdk7u/jdk7u/langtools/rev/41a303cb946e">http://hg.openjdk.java.net/jdk7u/jdk7u/langtools/rev/41a303cb946e</a><br>
<br>
6u34 JDK-6500343 compiler generates bad code when translating
conditional expressions<br>
<a class="moz-txt-link-freetext" href="http://hg.openjdk.java.net/jdk7u/jdk7u/langtools/rev/ddd110646d21">http://hg.openjdk.java.net/jdk7u/jdk7u/langtools/rev/ddd110646d21</a><br>
<br>
Cheers,<br>
<br>
-Joe<br>
<br>
<blockquote
cite="mid:CA+kOe0_vmpFxot2QADQLDBsUBHPLafoOPF79tx2Spg-Z1m9v8A@mail.gmail.com"
type="cite">
<div class="gmail_extra"><br>
<br>
<div class="gmail_quote">On Wed, Mar 13, 2013 at 1:47 PM,
Jonathan Gibbons <span dir="ltr"><<a
moz-do-not-send="true"
href="mailto:jonathan.gibbons@oracle.com" target="_blank">jonathan.gibbons@oracle.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">On 03/13/2013 12:47 PM, Andrew Hughes wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
4. Finally, this is just a thought, and I realise it
may run contrary to your<br>
promise of long-term stability and compatibility, but
I've been giving some thought<br>
to the long running issues we've had with javac in
OpenJDK 6. For those who are<br>
unaware, the javac in OpenJDK 6 is not the same as in
Oracle's proprietary JDK 6,<br>
but rather an early development version of the one used
in OpenJDK 7. I've been<br>
wondering if the best way of supporting this long-term
would be to use the tools<br>
from 7 in OpenJDK 6, with appropriate reversions to make
it compatible with 6<br>
(defaulting to 6 source/target, having builds pass the 6
TCK), rather than continuing<br>
to maintain the hybrid we have now. This would also
mean we'd be able to benefit<br>
more directly from any bug fixes or security updates
directed at the langtools<br>
present in 7.<br>
</blockquote>
<br>
</div>
You might want to bring this up on compiler-dev.<br>
<br>
-- Jon<br>
</blockquote>
</div>
<br>
</div>
</blockquote>
<br>
</body>
</html>