----- Original Message ----- > 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 >
Many thanks Joe!!! This is excellent. > Cheers, > > -Joe > > > > > > > > On Wed, Mar 13, 2013 at 1:47 PM, Jonathan Gibbons < > 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 > > > -- 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
