docker-library / openjdk

Docker Official Image packaging for EA builds of OpenJDK from Oracle
http://openjdk.java.net
MIT License
1.14k stars 471 forks source link

Remove now-defunct 8u and 11u builds #510

Closed tianon closed 1 year ago

tianon commented 1 year ago

See https://github.com/AdoptOpenJDK/openjdk8-upstream-binaries#readme and https://github.com/AdoptOpenJDK/openjdk11-upstream-binaries#readme 🙇

To be 100% explicitly clear: 8u and 11u are still maintained releases, they are just no longer provided here. Please find alternatives (Eclipse Temurin, etc) if you wish to continue using them.

Once Oracle stops publishing OpenJDK 18 builds, those will also be removed, and 19+ will be removed as soon as each release hits GA (as discussed previously).

From this point forward, our focus is on publishing only the EA builds from Oracle (since none of the other Java-providing official images currently do so).

tianon commented 1 year ago

(Draft waiting for https://github.com/AdoptOpenJDK/openjdk11-upstream-binaries/pull/28 :eyes: :heart:)

gdams commented 1 year ago

@tianon is it worth swapping these images to contain the Eclipse Temurin binaries? They are almost identical. I assume that a pretty large number of people rely on these images so it concerns me that they may be broken.

tianon commented 1 year ago

@gdams yeah, from a usability perspective, I'd absolutely agree -- unfortunately, I don't feel comfortable publishing Temurin as "official OpenJDK" (there are some pretty dramatic threads you can find in this repository if you want to read some of the history about which builds we've used in the past and the disagreements it has caused) :disappointed:

gdams commented 1 year ago

@tianon so here's my 2 cents...

The original discussions that you're referring to were about using AdoptOpenJDK as the openjdk base image. Several concerns were raised (mainly that AdoptOpenJDK wasn't able to TCK the binaries that they built)

Eclipse Temurin is in a very different position. It's hosted by an Open Source software foundation and passes the TCK tests that are required to confirm that the binary is compliant with the Java specification.

To quote the official docker guidelines outlines in https://github.com/docker-library/official-images#what-are-official-images, two of the tenets are a focus on Free and Open-Source software and multiple architecture support. Eclipse Temurin is therefore likely the most suitable drop-in replacement especially given the Synk Java ecosystem report that was shared in a related issue recently.

I'm certainly not suggesting that we should continue to maintain the openjdk image but I'm considered about the ramifications of deprecating a cast with 1B+ pulls. My suggestion ideally would be to simply redirect the users that are expecting the latest version to a similar (likely Temurin) container. E.g openjdk:8 would redirect to eclipse-temurin:8 for users expecting the "latest openjdk 8 build".

tianon commented 1 year ago

I'm referring to some of the older concerns/discussions (https://github.com/docker-library/openjdk/issues/320, for example) -- I definitely won't personally be making any new decisions about what to publish as "OpenJDK" in the future. :sweat_smile:

I'd love to do some kind of redirect, but the container pulling APIs don't support it (the message that's currently on https://hub.docker.com/_/openjdk is the best we can do).

gdams commented 1 year ago

I'd love to do some kind of redirect, but the container pulling APIs don't support it (the message that's currently on https://hub.docker.com/_/openjdk is the best we can do).

Could you not create a simple Dockerfile that essentially contains the other base image and tag this as openjdk:11?

FROM eclipse-temurin:11
CMD ["jshell"]

That way when people go to use what they believe to be the latest they will at least get a patched version of OpenJDK?

tianon commented 1 year ago

Yes, absolutely, that's exactly how I would probably implement this if I were going to do so :sweat_smile:

What I'm trying to say is that the problems with us doing so are not technical, they are political :see_no_evil: