A few emails later in the thread[0], it is noted... > ...who actually maintains the "official" Docker images for 8u and 11u? Github history for Dockerfiles points to no one I recognize from around OpenJDK. That, I think, is the main problem. [0]: https://mail.openjdk.java.net/pipermail/jdk8u-dev/2019-May/0... Edit: Actually linking to source (which I should've done from the beginning…)
Mystery meat OpenJDK builds strike again
31–40 of 56 posts
Re: Mystery meat OpenJDK builds strike again
#32Ubuntu Java packages are a joke as well and I stopped using them when I was having issues with the OpenJDK-11 package from apt. It turned out the the package wasn't packaging Java 11, but Java 10 instead, with a fake name [0]. I didn't check but they might rely on bad Debian packages just like Docker. --- [0]: https://twitter.com/d53r/status/1055403252286717952
TLDR: Ubuntu Bionic came out before Java 11 was officially released, they did not want to have Java 8 as their default, but Java 10 would not fit their LTS strategy since it is not itself an LTS release.
Having Java 10 in a package that claims to be Java 11 was a stopgap measure, and it has been fixed now, i.e. if you update that package you now get Java 11.
Re: Mystery meat OpenJDK builds strike again
#33Ubuntu Java packages are a joke as well and I stopped using them when I was having issues with the OpenJDK-11 package from apt. It turned out the the package wasn't packaging Java 11, but Java 10 instead, with a fake name [0]. I didn't check but they might rely on bad Debian packages just like Docker. --- [0]: https://twitter.com/d53r/status/1055403252286717952
There was a deliberate decision, not a random mistake: https://askubuntu.com/questions/1037646/why-is-openjdk-10-pa... TLDR: Ubuntu Bionic came out before Java 11 was officially released, they did not want to have Java 8 as their default, but Java 10 would not fit their LTS strategy since it is not itself an LTS release. Having Java 10 in a package that claims to be Java 11 was a stopgap measure, and it has been fixe…
When they updated OpenJDK to 11 [1] they didn't realize that some things have been dropped from the core project, and others have moved; as a result (among other things) JavaFX is now broken in Ubuntu Bionic. [2]
I think this is something inexcusable for an LTS.
[1] https://blog.ubuntu.com/2019/04/19/announcing-openjdk-11-pac...
[2] https://bugs.launchpad.net/ubuntu/+source/openjfx/+bug/18250...
Re: Mystery meat OpenJDK builds strike again
#34The guy who made those Docker images is not to blame in my opinion because he just trusted Debian, which is a renowned distro; he expected them to do the right thing. I believe Debian has a good reputation that they don't deserve anymore.
Re: Mystery meat OpenJDK builds strike again
#35The AdoptOpenJDK community (a consortium of vendors and users that produce business ready OpenJDK binaries) will work with the Debian maintainers to course correct this going forwards. If you’d like to get involved see https://AdoptOpenJDK.net
Re: Mystery meat OpenJDK builds strike again
#36There don't seem to be any debian emails about it: https://lists.debian.org/debian-java/2019/05/threads.html
The place where you'd want to look is the Debian Package Tracker entry for the source package, openjdk-8. Here's the URL: https://tracker.debian.org/pkg/openjdk-8 That has the current status of the package, and links to the bug tracker, which is where I'd expect things to appear!
Re: Mystery meat OpenJDK builds strike again
#37A few emails later in the thread[0], it is noted... > ...who actually maintains the "official" Docker images for 8u and 11u? Github history for Dockerfiles points to no one I recognize from around OpenJDK. That, I think, is the main problem. [0]: https://mail.openjdk.java.net/pipermail/jdk8u-dev/2019-May/0... Edit: Actually linking to source (which I should've done from the beginning…)
Re: Mystery meat OpenJDK builds strike again
#38This is indeed not the first time something like this happens and a good reason to get your openjdk builds from someone that has licensed the test suites and supports their builds. I remember having weird issues a few years ago with builds for both Centos and Debian/Ubuntu where they first took ages to get release builds out and then made it worse by basing their builds of pre-release versions rather than actual stab…
This is inaccurate (I work at Oracle on OpenJDK). Oracle provides the JDK under two different licenses: the commercial OTN, for support subscribers, and the free OpenJDK license (here: http://jdk.java.net/). Moreover, Oracle's OpenJDK builds are the official ones in the sense that bugs reported against OpenJDK must be reported against those (as those are the builds that the developers use). For 8u and 11u, the similarly official builds are these ones by Red Hat: https://adoptopenjdk.net/upstream
The thing about support is misleading becuase Java no longer has major releases (9 was the last one ever), and now has two upgrade paths: a gradual one: 9->10->11->12->... and a non-gradual one: 11->11.0.1->11.0.2.->...11.0.x->17 (neither of these is the same as the old model). The difference between upgrading from 11.0.2 to 11.0.3 and 11.0.2 and 12 can be very small (12 is not a major version), the gradual path is the recommended one as it will be the cheapest overall, and OpenJDK development is built around the gradual path. As far as OpenJDK builds go, Oracle supports only one of those paths for free (the recommended gradual one), while the other is for subscribers only. Note that in the recommended upgrade path, you will be supported by Oracle builds forever at no cost, and will never have to do another major upgrade again. So all the bug fixes and security patches for 11.0.2 are provided by Oracle, completely for free, in 12, which is not a major release.
As to the paid support path, this is how Oracle funds OpenJDK development. Oracle is the company that contributes >90% of the resources to OpenJDK (Here are the recent contribution stats for 11 and 12: [1][2]. Note that the stats do not consider contribution size.) So it's important to remember that all OpenJDK JDKs are developed primarily by Oracle, and it is Oracle's support subscription that funds OpenJDK development. And if, for example, you find a bug in Amazon Coretto, they will reproduce it on the Oracle (or Red Hat, depending on version) builds and submit it to the OpenJDK project for Oracle (or sometimes Red Hat) developers to fix.
[1]: https://blogs.oracle.com/java-platform-group/building-jdk-11...
[2]: https://blogs.oracle.com/java-platform-group/the-arrival-of-...
Re: Mystery meat OpenJDK builds strike again
#39Ubuntu Java packages are a joke as well and I stopped using them when I was having issues with the OpenJDK-11 package from apt. It turned out the the package wasn't packaging Java 11, but Java 10 instead, with a fake name [0]. I didn't check but they might rely on bad Debian packages just like Docker. --- [0]: https://twitter.com/d53r/status/1055403252286717952
There was a deliberate decision, not a random mistake: https://askubuntu.com/questions/1037646/why-is-openjdk-10-pa... TLDR: Ubuntu Bionic came out before Java 11 was officially released, they did not want to have Java 8 as their default, but Java 10 would not fit their LTS strategy since it is not itself an LTS release. Having Java 10 in a package that claims to be Java 11 was a stopgap measure, and it has been fixe…
It’s a ends justified the means situation and they got it terribly wrong.
Re: Mystery meat OpenJDK builds strike again
#40The AdoptOpenJDK community (a consortium of vendors and users that produce business ready OpenJDK binaries) will work with the Debian maintainers to course correct this going forwards. If you’d like to get involved see https://AdoptOpenJDK.net
I'm still astounded how much of an (intentional?) mess Oracle have made of Java and OpenJDK. If you search for Java you get to a Oracle page with a big download button and a cryptic yellow warning about license changes, with a little link at the bottom directing people to OpenJDK. The official OpenJDK builds they send people to have no Windows installer - they're just a ZIP of the JDK. There is no way for an ordinary…
As to an installer -- the JDK does not require any installation (just point JAVA_HOME at it). In addition, the JDK is for developers only. The days of the "system desktop JRE" are over, and it is against the recommended practice to have the JDK on non-developer machines. Instead, the recommended practice is to have the developer create a small custom runtime with jlink and bundle it with their application (or perhaps a runtime shared for all of the developer's applications, in case the users are all in the same company).