Differences between OpenJDK 8u and IcedTea8

[Andrew John Hughes]

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

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.

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