[icedtea] Patch for OpenJDK7 b126 support

[Dr Andrew John Hughes]

On 13:51 Wed 26 Jan     , Mark Wielaard wrote:
> On Wed, 2011-01-26 at 02:25 +0000, Dr Andrew John Hughes wrote:
> > On 01:14 Wed 26 Jan     , Damien Raude-Morvan wrote:
> > > Yes, I've successfuly build a b126 Icedtea+OpenJDK using patch I've send 
> > > yesterday and using Debian toolkit for building [0] (ie. it just prepare 
> > > configure options and apply some more patches).
> > > 
> > > To get tarballs, I'm using OpenJDK7 forest [1] and a simple script to
> > > 1) obtain revision by parsing .hgtags and grep "b126"
> > > 2) wget ${JDK_URL}/${module}/archive/${rev}.tar.gz
> > > 3) compute sha256sum && update Makefile.am
> > > 
> > > [0] https://code.launchpad.net/~drazzib/openjdk/openjdk7
> > > [1] http://hg.openjdk.java.net/jdk7/jdk7
> > > 
> > 
> > We use http://hg.openjdk.java.net/icedtea/jdk7 as the basis for IcedTea7
> > as mentioned on http://icedtea.classpath.org/wiki/Main_Page
> 
> I was thinking we maybe need a similar setup to icedtea6, which has
> icedtea6-hg for this purpose. Or am I missing something and is this
> "double redirection" of hg trees/forests easier to handle?
> 

At the moment, it's like comparing apples and oranges.

The icedtea6 tree is based on a release tarball (currently b21) provided by Oracle.
The space between such releases is often months (7 between b20 and b21).  icedtea6-hg
was created to work not against a tarball, but directly against the upstream forest
(i.e. it should be built with --enable-hg or by pointing --with-openjdk-src-dir at
an existing checkout).  While IcedTea6 uses release n, icedtea6-hg tracks the development
of release n+1.  When release n+1 is finalised and released, the changesets from icedtea6-hg
are pulled into icedtea6.  icedtea6-hg also pulls regularly from icedtea6 to keep in sync
with our changes.

The point of this is that it makes it easier to support new releases.  Rather than trying to
make all the necessary changes on release, they are made as changesets go in (e.g. we upstream
a patch so it is removed from icedtea6-hg).  We've used this for the last couple of releases,
and it seems to have resulted in a smoother transition to the new release.

In contrast, 7 has a much more rapid release schedule.  Releases occur on a weekly or bi-weekly
basis, so rather than it being a case of us watching hg until new releases come out, we can't
keep up with the releases (especially as 7 obviously has lower priority than work on 6).  The
IcedTea forest allows us to pull in a particular release, add any additional fixes we need to
make things work (either from IcedTea or upstream trees) and stabilise on a particular point.
We do this by using explicit changesets from the forest, whereas icedtea6-hg is meant to build
against the live repository.  When we ship a release of IcedTea7, it's against a known point
and won't be broken by changes pushed by Oracle.

In short, if we had either icedtea7 or a new tree, icedtea7-hg, tracking the jdk7 tree, it would
be unmaintainable as it would break on at least a weekly basis.

As things stabilise with 7, I expect it to shift to a process more like icedtea6/icedtea6-hg
and for 8 to take over the current 7 model.

Where I do hope 7 won't be like 6 is that we have much more active participation from Oracle
developers.  At present, we are still finding changesets over a year old that went into
Oracle's proprietary JDK6 release but have never been backported to OpenJDK6.  I hope that,
for 7, Oracle will be much more active in maintaining it.

> Thanks,
> 
> Mark
> 

Hope that helps,
-- 
Andrew :)

Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

Support Free Java!
Contribute to GNU Classpath and IcedTea
http://www.gnu.org/software/classpath
http://icedtea.classpath.org
PGP Key: 94EFD9D8 (http://subkeys.pgp.net)
Fingerprint = F8EF F1EA 401E 2E60 15FA  7927 142C 2591 94EF D9D8