The future of OpenJDK6

[Andrew Hughes]

----- 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