HotSpot just got Hotter - IcedTea6 support for latest HotSpot
Andrew John Hughes
gnu_andrew at member.fsf.org
Tue Dec 2 02:27:11 PST 2008
On 02/12/2008, Gary Benson <gbenson at redhat.com> wrote:
> Mark Wielaard wrote:
> > I think that supporting more than 2, lets call them "stable" and
> > "latest", might be a bit ambitious. We risk having to try to keep
> > up with all the different versions and duplicating all our patches
> > against more and more versions.
> I'd extend this and say can we not just support one? When Andrew said
> he was doing this last Thursday, my original thought was "great, we
> can get rid of all this two-versions-of-HotSpot stuff", so the thought
> of not only retaining it but possibly adding more is... unpleasant.
> My biggest issue was that, when there were problems with patches where
> there were two versions of something -- usually because of a new
> OpenJDK build -- people would often just fix one version and leave the
> other. So I'd wake up in the morning and suddenly my stuff wouldn't
> build and I'd spend all day making a fix that turned out to have
> already been applied in the "other" HotSpot. This is why I developed
> Shark out of the main tree fwiw. It was easier for me to deal with a
> huge dislocation every month or so -- when I was ready for it -- rather
> than potentially every day.
I know what you mean. With IcedTea7, we've actually been supporting 3
versions of HotSpot and each merge of IcedTea6 to IcedTea7 means
fixing patches to work with 7 (including the zero stuff).
This does simplify things because the default is now the OpenJDK7
HotSpot. This means IcedTea6 and IcedTea7 can use the same HotSpot
patches and hopefully you'll bump Zero up to this version too (I've
already patched it to at least build in 7, but it really needs a
sanity check). Then we are all on the same page at last.
Keeping the original around too is basically so we still build
something close to what Sun provides. However, if this bitrots
because no-one is bothered about using the version of HotSpot in the
main tarball, then we can throw them away. But I'd like to see how
things develop first before we do that.
Support Free Java!
Contribute to GNU Classpath and the OpenJDK
PGP Key: 94EFD9D8 (http://subkeys.pgp.net)
Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8
More information about the distro-pkg-dev