Adapting IcedTea for the new OpenJDK build system (build-infra)

Wed Jan 22 14:46:54 PST 2014

----- Original Message -----
> Hi,
> 
> I can't speak for the entire community, but I will share my experience
> and what I have seen.
> 
> * Magnus Ihse Bursie <magnus.ihse.bursie at oracle.com> [2014-01-22 15:57]:
> > Now, 1.5 years later and with the release of JDK8 getting closer,
> > I'm just curious on how the IcedTea project is doing with JDK8. I've
> > been skimming this list and I haven't seen any references to JDK8,
> > but I'm not sure what that means.
> 
> Mostly, it just means that most of us have been too busy with other
> things (including OpenJDK/IcedTea 6 and 7) to work much on IcedTea 8. We
> are tracking what needs to be added to OpenJDK8 for IcedTea8 here:
> http://icedtea.classpath.org/wiki/IcedTea_Patches_for_OpenJDK_8
> 
> But that's just patches and not most of the other work that has been put
> into IcedTea6 or IcedTea7.
> 
> > Have you started any IcedTea support for JDK8,
> 
> I am not sure; we haven't updated IcedTea8 in a while (at least, not
> that I know of).

The IcedTea 3.x series is on b80.  That's about the last time we had
chance to look at it.  It can also be built with JamVM, as Xerxes has
done some work on that.

Security updates have taken up all our time and, now they are occurring
every three months, that's only going to increase.  That has to be the
priority, together with fixes for the bugs people encounter, because
that's what people are actually using.

Personally, I feel 8 has come far too quick.  We're still seeing a lot
of interest in 6 and 7 is really only just now settling down, IMHO.
I'd have preferred 8 be released in maybe two or three years time,
but it feels like there is a rush to obsolete things almost as soon
as they are released.

> 
> > or did it actually
> > end up with IcedTea not being needed for JDK8?
> 
> Speaking for myself, I have actually added a non-IcedTea8 build of
> OpenJDK8 to Fedora [1]. It is missing lots of things that are maintained
> in IcedTea, though. Still, as a proof of concept, it seems like it is
> mostly working.
> 
> I think we will need _some_ variant of IcedTea8 for OpenJDK8. Even
> ignoring all the non-OpenJDK parts of IcedTea (such as alternate VMs and
> ports), we will need it for release branches. We need release branches
> (and releases/tags). In lots of distributions, major version updates are
> not allowed and we need to have release branches that just contain
> security fixes (and major bug fixes) but nothing else.

I concur with Omair on this.  IcedTea has always been about providing
OpenJDK in a more consumable form and, though we no longer have to
work around most of the technical issues that were apparent at the
start, we still end up providing things like a more usual release cycle
and somewhere for people to put fixes.

It's still far too hard to get stuff into OpenJDK upstream; it varies
depending on what component you want to get it into and also, bizarrely,
who is proposing the fix. I've had no problem getting build fixes in,
especially with the new system, presumably because we're now well known
and in contact with the people working on it.  On the other hand, I still
can't commit to HotSpot, even as an OpenJDK reviewer.  I have no idea how
HotSpot fixes make it from 8 into the update cycles, to the point that I'm
on the verge of giving up.  I'm paid to work on this, but my time is still
limited as mentioned above.  It doesn't surprise me we don't see many
volunteers.

However, what makes me saddest is when I see someone post a patch who hasn't
before and it is simply ignored.  No response at all.  I understand people
are busy at Oracle too, but sometimes this just comes across as rude.

The other big thing is there are no security release tarballs.  I discussed
this with Dalibor in October 2012 on the 7u list, but it seemed to go nowhere.
There are at least tags, but it means to get a release with just the additional
security fixes, you have to pull that tag from each repo and hope you don't
end up with stuff from the next release.  This could very easily be made simpler
for people, but I got the impression that there was no desire to target end users.

> 
> > Is the new build system of any help?
> 
> IMO, the answer is a big "YES". The new build system (thanks to it's
> autotools nature) is both familiar and sensible when it comes to
> adding/removing and modifying things. I have found most fixes rather
> straight-forward. If I have been a little slow in trying to upstream
> them, it's because I was hesitant to re-implement the build fixes in
> both the old build system and the new build system.

I have had chance to try it since b80 at which point both the new and old
were present, but only one was usable.  I found it all very confusing and
most of my time was spent fixing regressions, so I didn't have the best
experience.  Finding two places that seem to do the same thing, but then
you find one isn't being used any more, isn't helpful.  I understand the
old build system has finally been thrown out (long overdue) so things
may well have improved.  I'm sure the configure step now makes it easier
for people building raw OpenJDK, but as we've had that with IcedTea from
the start, it's not a huge boon for us.  What was odd was that some options
seemed to be available in configure while others were still only in make
variables; again this may now have been fixed.

I guess the main effect it has had is that it's made it more difficult to
get things in, because we're supposed to go 8->7->6, but if the fix contains
build changes, those changes will be completely different on 6 & 7.  I'm
still not sure how we deal with this going forward.

People claim the new build is faster, but I honestly didn't really notice.
Maybe this was just because doing parallel builds with the old build was
so obscure that people didn't enable it?  IcedTea has for a long time, so
I've always been building on 8 cores where supported.

> 
> Thanks,
> Omair
> 
> [1]
> http://pkgs.fedoraproject.org/cgit/java-1.8.0-openjdk.git/tree/java-1.8.0-openjdk.spec#n427
> 
> --
> PGP Key: 66484681 (http://pgp.mit.edu/)
> Fingerprint = F072 555B 0A17 3957 4E95  0056 F286 F14F 6648 4681
> 

I'm sorry this all sounds so negative, but, from my perspective, I
have enough on my plate already without 8 coming into the picture.
-- 
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