Live data from Hacker News

Mystery meat OpenJDK builds strike again

mail.openjdk.java.net

41–50 of 56 posts

Re: Mystery meat OpenJDK builds strike again

#41
post #35

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

The current thinking is that end users are not supposed to install Java - it will be bundled with every application. That kind of solves the problem, but I guess we'll have to forget about writing small utility programs in Java.

Also, complicating things a bit if you want a traditional shared Java installation, AdoptOpenJDK has apparently been refused a license for the test suite, making it not quite properly offical Java.

Re: Mystery meat OpenJDK builds strike again

#42
post #32

Earlier quoted context omitted.

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…

Unfortunately by doing this they made another mess. 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…

TLDR; I agree, but I understand how this happened.

The logic seems to have been:

* Ubuntu 18.04 is a LTS release.

* LTS releases should only incorporate software that is supported on a similar lifecycle.

* OpenJDK 8 was moving out of its support window early in the lifetime of Ubuntu 18.04.

* OpenJDK 11 (the next long term supported JDK) was not going to be released until after the release of Ubuntu 18.04

* OpenJDK 9 and 10 were short term releases so they weren't options

* The move from Open JDK 8 to Open JDK 9 included a lot of breaking changes (from project Jigsaw/modularisation)

So a compromise was necessary. From a purist packaging point of view it makes sense; release JDK 10 as "JDK 11" and silently upgrade under the covers when possible. In theory this would only involve minor changes and the 'wrong' version would only be there for the first few weeks of the release. In practice there were some breaking changes - enough that the backporting of OpenJDK 11 into Ubuntu 18.04 actually took rather a long time. It's also, of course, really confusing when you "sudo apt install openjdk-11" and something totally different happens.

The problem with staying on OpenJDK 8 (perhaps the obvious approach) is that in an unsupported state it would lack security fixes. In practice of course several alternative upstreams are now available supporting it.

Hopefully it will all go with fewer surprises when we get to the next LTS edition (Ubuntu 20.4).

Re: Mystery meat OpenJDK builds strike again

#43
post #41
post #35

Earlier quoted context omitted.

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…

The current thinking is that end users are not supposed to install Java - it will be bundled with every application. That kind of solves the problem, but I guess we'll have to forget about writing small utility programs in Java. Also, complicating things a bit if you want a traditional shared Java installation, AdoptOpenJDK has apparently been refused a license for the test suite, making it not quite properly offical…

> but I guess we'll have to forget about writing small utility programs in Java.

Developers will continue using the JDK (for which no installation is necessary; just setting JAVA_HOME). A tool suite intended for users will share the same runtime. And when it comes to small, user-oriented, standalone utilities, Graal's native image makes that more compelling than ever.

Re: Mystery meat OpenJDK builds strike again

#44

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

Pretty much every enterprise vendor has an OpenJDK build. I work for Pivotal. We've been building and shipping the OpenJDK from source for years (mostly Java buildpack, but we use it for anything that we ship that requires a JVM). Like our peers at other enterprise software vendors we spent a lot of engineering making the process smooth and traceable.

I think more of the industry will move towards AdoptOpenJDK builds. There's a lot of value in combining forces to produce the same byte-identical binaries for everyone.

Re: Mystery meat OpenJDK builds strike again

#45

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

Pretty much every enterprise vendor has an OpenJDK build. I work for Pivotal. We've been building and shipping the OpenJDK from source for years (mostly Java buildpack, but we use it for anything that we ship that requires a JVM). Like our peers at other enterprise software vendors we spent a lot of engineering making the process smooth and traceable. I think more of the industry will move towards AdoptOpenJDK builds…

Jetbrains do as well, they store theirs on bintray.

It's all a bit of a mess tbh and particulary frustrating from the outside where you aren't a full time java dev.

Re: Mystery meat OpenJDK builds strike again

#46
post #32
post #30

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

> There was a deliberate decision, not a random mistake

Debian's mess was not a random mistake. "Whoopsie, I somehow deleted the EA tag from the version string - actually it must have deleted itself. Anyway, I've started uploading it to the package index, it's too late now."

Re: Mystery meat OpenJDK builds strike again

#47

Earlier quoted context omitted.

Unfortunately by doing this they made another mess. 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…

TLDR; I agree, but I understand how this happened. The logic seems to have been: * Ubuntu 18.04 is a LTS release. * LTS releases should only incorporate software that is supported on a similar lifecycle. * OpenJDK 8 was moving out of its support window early in the lifetime of Ubuntu 18.04. * OpenJDK 11 (the next long term supported JDK) was not going to be released until after the release of Ubuntu 18.04 * OpenJDK 9…

I saw earlier in this thread of blaming Debian, but all I'm seeing is Ubuntu snafus

Re: Mystery meat OpenJDK builds strike again

#48
debian is not a trustworthy source of software if you expect it to be close to the upstream version.

They will change things around completely (MySQL/MariaDB), cause terrible bugs (OpenSSL), create crazy/renamed/weird versions (apache httpd -> apache2), etc etc.

Frankly you are lucky to get something this close to real java and not a shell script wrapping GCJ or whatever.

Re: Mystery meat OpenJDK builds strike again

#49

debian is not a trustworthy source of software if you expect it to be close to the upstream version. They will change things around completely (MySQL/MariaDB), cause terrible bugs (OpenSSL), create crazy/renamed/weird versions (apache httpd -> apache2), etc etc. Frankly you are lucky to get something this close to real java and not a shell script wrapping GCJ or whatever.

>And any day Debian decides to stop using Foo, is always a happy day for Foo's upstream. Finally, the stream of bugs matching the below template will stop spamming Foo's bug tracker:

>> Debian X.x (stable) >> foo >> >> .

>The only appropriate reply to such bugs IMHO is:

>> Fuck off. And don't come back before switching to a distribution >> with a non-broken definition of stability.

>Unfortunately, most upstreams always try to stay civil.

Re: Mystery meat OpenJDK builds strike again

#50
post #38

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

> Oracle seems to have stepped away from this and only offers limited time support for their own JDKs which also cost money. 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 reporte…

That's the Oracle pitch. The practical implication is that you don't get your openjdk builds from them if you want to avoid the audits, licensing, etc. Paid support is also offered by others so they don't do this exclusively. This has been true since they acquired Sun. I find this odd because that was arguably the most valuable thing they acquired from them.

BTW, v9 was a non LTS release, just like 10. v8 was the last traditional release. V11 is a relatively short lived LTS release. Hence Amazon and others stepping up to fill the void left by Oracle no longer offering long term support for free.

Post reply on HN