The future of OpenJDK6

Andrew Haley aph at redhat.com
Thu Mar 14 02:27:33 PDT 2013


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?

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

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

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


More information about the jdk6-dev mailing list