back

by dcminter·7y ago·view on hn ↗
I for one would very much like to see this bug in 18.04 fixed as a priority:

https://bugs.launchpad.net/ubuntu/+source/openjdk-lts/+bug/1...

The Java 11 package installs Java 10. This was supposed to be a short term hack (because Ubuntu's long term supported version 18.04 was being released shortly before Java's long term supported version 11) but it's been a good while now - six months or so.

The short term support version 18.10 of Ubuntu has Java 11 so it's very non-obvious what the blocker is.

To me this seems like a really poor choice. The result of installing the Java 11 package but getting Java 10 clearly fails the principle of least astonishment. If we can live without the fix a quarter of the way to the next LTS edition of Ubuntu then we could have lived with Java 10 as the preferred (and correctly named) package in the first place.

Meanwhile the bug asks us not to spam with requests for updates yet there's no suggestion of where we can go to gauge what the timescales we're up against are.

It definitely dents my confidence in Ubuntu as a well organised distribution.

3 comments
Reminds me of when they replaced ffmpeg with avconv. As in, installing 'ffmpeg' would give you something completely different.
Or when the proprietary Broadcom driver was replaced by open source version, although it was still lacking in features and we had to use LAN cable for about 6 months until it reached feature parity.
Debian's stretch-backports had a slightly awkward transition phase where "openjdk-11" started as Java 9, then 10, and then 11... took about a month for it to get "caught up". They did it because the JDK can be bootstrapped by version N-1, so building Java 11 required Java 10, which required Java 9 to build, which in turn required Java 8, which is the version in stretch anyway.

Though I doubt and hope Ubuntu didn't base their stuff on the backports branch...

That seems odd to me - why could one not install (or build) package N-1 in order to build package N ? i.e. why does it all need to be the same package name?
It would have required moving openjdk-9 and openjdk-10 into backports only to be removed later. These packages were already removed from unstable and testing, and I assume it would have made things only more of a hassle... Also I guess it meant that installing openjdk-11 on stretch-backports would eventually gain you Java 11 (and it does now).

I'm not a Debian maintainer. They'll probably have a better answer if you asked them :)

This looked like a decent idea when the package was created, but turned into a disaster, an example of how NOT to do things.
Yeah, I'm sympathetic to the Ubuntu maintainers - at this point there are teams/companies which have built some server application/service on Ubuntu 18.04, and expect no backwards-incompatible changes for 5 years (the classic stable distro objective), but if openjdk-11 is updated from openjdk 10.x to 11.x then some stuff will stop working. I'm curious how they'll resolve it (and I think an additional half-year past the openjdk-11 release is reasonable, in the overall 5-year timeframe).

(Meanwhile, apparently, some users have come to expect an upstream release to get into ubuntu stable updates within 2 days ?!)

Jdk 10 is unsupported already.
Stable linux distros have a long history of backporting security patches themselves - RHEL does this the most/longest, Debian and Ubuntu somewhat less but still a lot. They've given up on web browsers, but for most other stuff, definitely including java, they certainly can and do support what they have released. In the linked issue, it notes that they already have backported some security fixes that were in 11.0.1 to openjdk-10.
Possible, but is it a good idea?

If the package is called "openjdk-11", I want JDK 11.