----- Original Message ----- > Responding to one point below, > > On 3/13/2013 12:47 PM, Andrew Hughes wrote: > > ----- Original Message ----- > > [snip] > > > 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. > > > What concrete issues with OpenJDK 6 javac are you referring to? Are > there bugs for them? >
We tend to come across inferencing issues which don't appear on either the proprietary JDK 6 compiler or the OpenJDK 7 one e.g. http://mail.openjdk.java.net/pipermail/jdk6-dev/2010-September/002008.html > > 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. > > The above is an incorrect categorization of the javac in OpenJDK 6 > and > more broadly the langtools repository in OpenJDK 6. > > All of OpenJDK 6 initially branched off of (Open)JDK 7 build 20 or > so. > There were fixes in javac and more broadly langtools at that time > compared to JDK 6 GA. Those fixes were largely appropriate to a Java > SE > 6 comiler and therefore kept in; inappropriate changes were backed > out. > At least during the 3+ year tenure when I was release manager of > OpenJDK > 6, the langtools team made sure that all javac fixes that went into > the > Sun/Oracle proprietary JDK 6 also went into OpenJDK 6. Therefore, the > OpenJDK 6 javac has had a strict superset of the fixes in Sun/Oracle > JDK > 6. The compilers in both OpenJDK 6 and JDK 6 pass the relevant JCK > tests. > > The OpenJDK 6 javac and JDK 6 javac are different, but I would argue > the > OpenJDK 6 javac was and is better. > I apologise. I should have clarified that with 'was originally based on an early development version'. I'm aware it's had work since. Backports even caused TCK6 failures for us at least once :) What I do know is that there are issues that only appear on *that* javac. It also has been maintained in that way of late. The last non-tag commit is: changeset: 126:6fa1f24a215a tag: jdk6-b25 user: jjg date: Fri Sep 16 16:18:46 2011 -0700 summary: 7091528: javadoc attempts to parse .class files about 18 months ago. > The differences between the OpenJDK 6 and JDK 6 versions of other > components vary by repository and area. As you noted, for some time > Red Hat has kept the hotspot repo of OpenJDK 6 generally in sync with > the > stabilized HotSpot express releases. At least times in the past, the > jaxp, jaxws, and cobra OpenJDK 6 repos have been functionally > identical > to their JDK 6 counterparts. Some of this is detailed in an old blog > post: > > "OpenJDK 6: Logistics of Partial Merge with 6u10" > https://blogs.oracle.com/darcy/entry/openjdk_6_logistics_of_partial > > That leaves the "jdk" repo where most of the core libraries live > (java.lang, java.util, java.awt, etc.). There has never been an > analagous grand merge between what would logically be the jdk repo of > the JDK 6 train and the jdk repo of OpenJDK 6. However, this has not > seemed to be too much of an impediment to usability or to backporting > security patches and other fixes as needed. I can't really comment on the proprietary JDK 6 codebase any more than what I can infer as I obviously can't see the code. I know we've backported quite a few changes from 7 to 6 (nearly all JDK) which were ported to 7 from the proprietary 6 codebase by Sun/Oracle before that. However, there's been no structure to this. It's just been a case of seeing a commit to 7 which references coming from the proprietary 6 tree, or finding a bug that indicates the fix was committed there. I have no idea how complete things are. > > > 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. In closing, I'd like to welcome this new > > chapter in the life of OpenJDK 6 and I hope it is successful in > > continuing existing community involvement, and hopefully taking > > things > > even further. Thanks, > > The code in the (Open)JDK 7 uses the Java SE 7 versions of the > javax.lang.model.* API, which differ from the Java SE 6 versions. It > would be a "small matter of programming" to adjust the rest of the > javac > sources accordingly. Note that some portions of the langtools repo in > OpenJDK 7 outside of parts involved in bootstrapping may rely on Java > SE > 7 APIs. > Yes, these are the reversions I was referring to i.e. enough to get it building and passing the 6 TCK. My naive thought is that this would be a more stable process than attempting to backport random changesets from 7, as it's already been applied once to create the original 6 javac. > Whether or not undertaking this exercise would lead to lower > long-term > maintenance costs I cannot say, but it is not clear to me that it > would. > As I say, I was just musing on the idea rather than committing to it. We'd have to investigate it in more detail first. I was just throwing the thought out there and your feedback has been very helpful. >From what you've said, it sounds like the javac is closer to the one in 7 than I'd imagined. > -Joe > -- 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
