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.
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 :)
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 ?!)
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.
Apparently 18.04.2 LTS has been released, as that's what my box reports running now. I don't see any clear announcements of the actual release, but perhaps they're just hard to find on the various ubuntu wiki/planet/mailing list/etc... sites.
Does it include the fix for apt's recent mirror redirect vulnerability? If not, any update to a fresh system would be trivially susceptible to a MITM attack if redirects aren't disabled. This includes docker images as well: https://justi.cz/security/2019/01/22/apt-rce.html
Canonical really should enable https as an additional layer of protection. This isn't the first time a bug in apt's authentication was found and it's unlikely that this bug will be the last.
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.