Differences between OpenJDK 8u and IcedTea8

Fri Jan 10 10:42:16 UTC 2020

Hi Andrew,

thanks a lot for the really useful details about the history and
current state of IcedTea and the various related OpenJDK repositories!

On Fri, Jan 10, 2020 at 3:13 AM Andrew John Hughes
<gnu.andrew at redhat.com> wrote:
>
> [Personal hat on mostly, but I don't believe my personal e-mail is
> subscribed to this list...]
>
> On 09/01/2020 11:11, Volker Simonis wrote:
> > Hi,
> >
> > I've just realized that ojk8u-dev currently doesn't build correctly if
> > configured with "--with-zlib=system". This was surprising to me,
> > because I know that most  (all?) Linux distributions link their ojdk8
> > packages dynamically against the system provided libz (and I could
> > verify this on my Ubuntu machine).
>
> They do, since pretty much OpenJDK's inception, I believe. As you've
> probably now gathered from discussion with Severin, and contemplation of
> PR1413 [0], this issue is local to some distributions and I can't recall
> ever being able to replicate it myself. I suspect those distros that
> need it have had it in their packages now for so long they've forgotten
> it's even needed.
>
> >
> > So I took a peek at the IcedTea 8 repo [1] and found that this issue
> > was fixed there since a long time ago [2]. I was also surprised to see
> > that the IcedTea 8 jdk repository actually contains quite some fixes
> > and downports which are not in OpenJDK 8u yet [3] (e.g. HiDPI
> > support).
> >
> > Now that Red Hat is leading the OpenJDK 8 updates project, is there
> > any specific reason (except the lack of time :)) why you still keep
> > these changes in IcedTea instead of pushing them upstream to
> > jdk8u-dev?
>
> Well, first of all, IcedTea is maintained by me in a personal capacity
> and has been for some time. Red Hat don't use 3.x and only consume the
> forest directly for 2.x. The last time their packages were fully
> IcedTea-based was for OpenJDK 6, may it rest in peace.
>
> In general, yes, time is the main factor. There is a backlog of years of
> stuff that needs to be upstreamed. Pretty much anything that is trivial
> to do has been. My eye is currently on proposing the AArch64 port for 8u
> once the CPU is out of the way, as I believe that's probably the main
> reason most distros don't use vanilla OpenJDK 8, as far as I'm aware :-)
>
> OpenJDK has a chequered history of contributions. Without indulging in a
> political rant, the current relative ease of getting stuff into 8u & 11u
> (I can't speak for HEAD, it being that long since I had chance to commit
> stuff there) is a world away from even last year, and certainly when
> OpenJDK started and didn't even have repositories for the first year.
>
> Stuff built up outside of the main trees not because people wanted to
> keep things outside the project (quite the opposite actually), but
> simply because people need to get stuff done and ship to customers. I
> know I've had stuff sat on mailing lists for months before with no
> response, and I'm not alone. Things are much better now, but there's
> still a legacy of that. Most, if not all of us, here working on OpenJDK
> are being paid to do so. I think that history has largely killed off
> more casual interest. It's possible to see a good side to that, so I'll
> leave it to debate. My main point is that this kind of thing is
> disheartening, and eventually people just give up.
>
> So, IcedTea has this legacy of being the home for getting from upstream
> to something that can be shipped. In the beginning, it got rid of the
> binary blobs that were needed to even build OpenJDK. Today, it mirrors,
> in a distro-agnostic way, what distros that don't use it are also doing,
> in shipping a bunch of extra ports and patches.
>
> I maintain IcedTea personally, and use that for the Gentoo ebuilds. For
> Red Hat, I maintain the RHEL & Fedora RPMs. There are some more patches
> in IcedTea than in the RPMs (including this patch & the HiDPI stuff you
> spotted), but I would say that the RPMs are closer to IcedTea than
> upstream 8u (i.e. jdk8u/jdk8u).
>
> Primarily, IcedTea & the RPMs both have the AArch64 port & Shenandoah
> GC, which can be found for 8u under the shenandoah-jdk8u repository in
> the aarch64 port project. For Shenandoah, we use the exact same HotSpot
> tree as the RPMs and I believe IcedTea is unique in allowing the switch
> between 8u HotSpot with aarch64 port from the IcedTea trees, 8u HotSpot
> with aarch64 port & Shenandoah from aarch64-port/shenandoah-jdk8u & 8u
> HotSpot from the aarch32 port using a simple configure switch. The
> Gentoo package utilises this in turn as a USE flag, so end users can
> decide whether they want Shenandoah built or not. I actually realised
> recently that this means IcedTea's HotSpot is a good starting point to
> upstream aarch64 without the Shenandoah code being in the way.

I think that would be much appreciated by many people in the OpenJDK community.

>
> Since 8u switched to being led by Andrew Haley, and the current
> processes were implemented, IcedTea 3.x has largely just being keeping
> up-to-date with 8u and that mountain of patches is slowly being
> upstreamed. I expect IcedTea to hang around, because it's still
> providing a role of better build defaults and as the home for auxiliary
> stuff like SystemTap tapsets & desktop files that I'm not sure will ever
> be upstreamed. Certainly there's stuff in there that would need to go in
> trunk before they make any backport to 8u & 11u, and the more rapid
> movement of that now actually makes that harder.
>
> Regarding the patches you mentioned, the HiDPI stuff ended up in IcedTea
> as a requirement for backporting Gtk3+, which we did ahead of upstream
> and through tracing back all the requisite backports rather than the way
> it was dumped into upstream 8u in one big patch. The IcedTea release
> notes have a trace of all these bugs that needed backporting, so we can
> certainly work out which ones were brought in with that Gtk3+ patch for
> 8u and which weren't. But again, it takes time and I don't really see a
> huge demand for it.
>
> Going back to this build fix itself, the main reason that's not upstream
> is because it's not my patch and so I don't have the rights to
> contribute it to 8u. I also can't come up with something similar myself
> because I can't replicate the bug. If you can, then you're welcome to
> submit an 8u patch and we'll include it in 8u252.
>

I've meanwhile found out why you and others couldn't reproduce the
problem. It's due to GCC configuration differences on RHEL/Fedora and
other distros. On Ubuntu, where I was building,  COLLECT_GCC_OPTIONS
contains "--as-needed" by default which breaks the build if a library
appears on the command line before an object that depends on it. On
RHEL (5.3 was the only one I could check), this is not the case, so ld
defaults to "--no-as-needed" and is still able to successfully link.
I'll file a jdk8u request for this trivial fix.

> >
> > Thank you and best regards,
> > Volker
> >
> > [1]  http://icedtea.classpath.org/hg/icedtea8-forest/jdk
> > [2] http://icedtea.classpath.org//hg/icedtea8-forest/jdk?cmd=changeset;node=c5b4565befea
> > [3] http://icedtea.classpath.org/hg/icedtea8-forest/jdk/search/?rev=PR1&revcount=100
> >
>
> [0] https://icedtea.classpath.org/bugzilla/show_bug.cgi?id=1413
>
> Hope that explains some of this,
> Thanks,
> --
> Andrew :)
>
> Senior Free Java Software Engineer
> Red Hat, Inc. (http://www.redhat.com)
>
> PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net)
> Fingerprint = 5132 579D D154 0ED2 3E04  C5A0 CFDA 0F9B 3596 4222
> https://keybase.io/gnu_andrew
>