The future of OpenJDK6

[Andrew Hughes]

----- Original Message -----
> On 03/13/2013 07:47 PM, Andrew Hughes wrote:
> > ----- Original Message -----
> >> Oracle ended public updates of JDK6 at the end of last month.
> >>  Many
> >> people seem to have concluded that the OpenJDK6 project will
> >> therefore
> >> end at the same time.  This is incorrect: OpenJDK6 will continue,
> >> but
> >> will be maintained by the community outside Oracle.
> > 
> > 1.  Oracle had three main roles in relation to OpenJDK 6; acting as
> > gatekeeper over which patches were accepted into the repository,
> > providing security updates and making releases.  The third of these
> > doesn't seem to be addressed above.  Will new releases of OpenJDK 6
> > be made?  IcedTea for OpenJDK 6 uses release tarballs as a base so,
> > unless there are further releases, none of the changes made
> > upstream
> > in OpenJDK 6 will be consumed by IcedTea downstream.  I believe we
> > are already overdue a new release as there is no release of OpenJDK
> > 6 containing the last three sets of security updates.
> 
> Indeed, we need to make a new release of OpenJDK 6 with the security
> patches.  There may be infrastructure issues here as we don't AFAIK
> have access to Oracle servers on which to place release tarballs.  Or
> do we?
> 

Not as far as I know, but I don't see how it matters where they are located,
as long as people are notified of the location.

I'm more concerned that they happen promptly and tarballs are produced with
the same form and contents. Hopefully, there is some obscure Makefile target
that creates them but I'm not aware of it offhand.

> > 2.  What many people actually see as OpenJDK 6 at present, in the
> > form of their GNU/Linux distribution package, is actually IcedTea
> > for OpenJDK 6.  Unlike 7, where the changes in IcedTea are just to
> > make it "distro-ready" (using system libraries, etc.), there are
> > now
> > so many backports and other fixes local to IcedTea 6 that it is
> > effectively a different beast altogether.  Will OpenJDK 6 be open
> > to
> > accepting some of these fixes, many of which were added to the
> > proprietary version of JDK 6 maintained by Oracle a long time ago,
> > so the two can eventually be in sync?
> 
> That would, in my view, be a huge waste of effort.  It also risks
> breaking things for no net gain.

The gain would be to shift the focus from IcedTea6 to OpenJDK6.  Pretty
much no-one uses OpenJDK6 directly, as far as I'm aware.  All the distro
packages I've seen use IcedTea6 to build it with these patches applied.
When I last tried OpenJDK6, I had to push four changesets upstream just
to get it to build on a modern system.

If things were broken with these patches, we'd surely know about it because
everyone using OpenJDK 6 packages is using them with these patches.

I agree it's a lot of wasted effort for no technical gain.  It would be simpler
and easier to just stick with IcedTea.  But that does make OpenJDK 6 a bit
pointless, to be frank.

> 
> > 3.  The largest contributions to OpenJDK 6 from Red Hat have been
> > the merges of new versions of HotSpot, upgrading it from 11 through
> > 14, 16 and 19, to its current version of 20.  Given appropriate
> > testing, is moving to a newer version of HotSpot a possibility?
> 
> Yes.  I believe that it is necessary to make some small changes to
> HotSpot to make it fully Java SE 6 compatible, but we should do this.

Well, as I say in the blog, it builds and passes the jtreg tests with hs23.
You're welcome to validate it further with the proprietary tests in the TCK.

> 
> > 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.
> 
> No.  As explained by the Javac team, javac 7 does not accept
> precisely
> the same language, even in "Java 6" mode, and such a change would
> risk
> breaking builds all over the place.  This is exactly the kind of
> change that I wish to prevent.
> 
> > 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.
> 
> I hope so too.
> 
> Andrew.
> 

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