docker.io/library/openjdk:24 Not found

Since this morning we are getting an error pulling the openjdk:24 image from docker. Has this been removed or has something happened to this? I've tried this both on the cloud and locally and it's getting the same result:

   8 | >>> FROM openjdk:${VERSION}
   9 |     COPY --from=build /home/app/project/build/libs/*.jar /app/service.jar
  10 |     ENTRYPOINT ["java", "-jar", "/app/service.jar"]
--------------------
ERROR: failed to solve: openjdk:24: failed to resolve source metadata for docker.io/library/openjdk:24: docker.io/library/openjdk:24: not found

The same thing is also happening for the other Java versions too.

I've tried various images, but what were working now seem to be missing e.g.

ARG VERSION=24
FROM openjdk:${VERSION}-jdk as build

Any help would be appreciated.

The same here pulling the openjdk:17-alpine

ERROR: failed to solve: openjdk:17-alpine: docker.io/library/openjdk:17-alpine: not found

It looks like the issue is caused by this PR - #550

Also happening with JDK-21
ERROR: docker.io/library/openjdk:21-jdk-slim: not found

Also happening with JDK-21-oracle
docker.io/library/openjdk:21-oracle: not found

Same happening for openjdk:11

same issue openjdk:8-jdk-slim not found

Likewise for openjdk:11-jdk-buster

@yosifkit

@yosifkit @timothygachengo was it intended to remove all those tags #550??

The comment #550 notes that this image is not GA and is listed on Docker Hub as a pre-release / non-production OpenJDK build. For production use, we should switch to one of the images recommended in the README.

I didn't even know that myself...

Ok, so change the reference from openjdk:26 to something like openjdk:26-ea or *-ea-jdk. Makes sense to me - I can leave this issue open if someone else wants to make more comments, otherwise please feel free to close it as and when necessary.

Same with openjdk:21-jdk, was it intended?

experiencing the same issue with openjdk:23

See Retiring OpenJDK Project Builds for JDK 11 and JDK 8 for more information.

Yes, it was 100% intentional, and none of the images referenced here should be used (and this is one of the only ways we have to explicitly signal that -- they've all been dead and deprecated and unmaintained for 3+ years).

Copying my note from docker-library/official-images#20210 (comment):

My personal suggestions for users affected by this removal, in decreasing order of suggested precedence:

switch to https://hub.docker.com/_/eclipse-temurin (it's literally plain compiled builds of OpenJDK for this exact intent, created and maintained by some of the very folks who maintain OpenJDK, and is actively supported/maintained, unlike almost all tags of the openjdk image)

switch to a more specific/explicit/known-outdated tag (openjdk:8u342-jre, for example)

build your own image

In other words, if you want to continue using images from the openjdk repository on Docker Hub, I want to make sure it is very clear to you that the builds you are using are not actively supported or maintained in any way.

@tianon

@tianon I ask that in the future you and others consider removing images not on a US election day.

My company (Newsday, a news company serving Long Island, New York) had to deal with putting out a fire because this image tag was removed. Today in the US there is some local elections that are being widely covered (NYTimes, AP, Reuters, etc) so downtime can be quite disruptive.

Yes we should have been using a different image (we were using openjdk:8-alpine) and/or a newer version of Java altogether. However upgrading Java versions requires a lot of time and work to be put in. Not everyone at our company understands this so it can be quite disruptive when this kinda thing happens seemingly suddenly. This also applies to a lesser extent when switching OpenJDK builds. At the end of the day, our company as a whole doesn't appreciate the importance of maintenance tasks like keeping our versions of Java and Node.js up to date. And I'm certain this kind of attitude is quite common among companies in general.

To be clear, I'm not asking for these deprecations to be called off, not at all. All I ask is that in the future, you don't remove a broad swath of images like these on the day of a widely covered US election. Or better yet if possible, don't remove them on a day where wide news coverage around any event, be it election or not, is expected.

Sorry, I honestly forgot about the election day because despite being in the US, I don't get one. 🙈 If I had recalled it, I would've adjusted, and that's on me.

That being said, you do not need to upgrade your Java version -- there are several alternatives that all maintain builds of Java 8:

Of these, eclipse-temurin:8 is probably the most close/faithful to what you were using, as it's extremely vanilla builds of upstream OpenJDK, and even includes Alpine variants of Java 8 (https://github.com/docker-library/docs/blob/master/eclipse-temurin/README.md#supported-tags-and-respective-dockerfile-links), despite the "Portola Project" not being finished until JDK 18. 😅

(Added note: the deprecation of our builds isn't new -- openjdk:8-alpine has been unmaintained and honestly unsafe/unfit for production use for many years now.)

Thanks, yeah we wound up switching to eclipse-temurin:8-alpine (before 1 PM EDT) and have been regression testing since. The migration seems to have gone ok.

Sorry, I honestly forgot about the election day because despite being in the US, I don't get one. 🙈 If I had recalled it, I would've adjusted, and that's on me.

Can't blame ya considering you don't have an election yourself and I'm guessing you don't work for a news company.

(Added note: the deprecation of our builds isn't new -- openjdk:8-alpine has been unmaintained and honestly unsafe/unfit for production use for many years now.)

Yeah that's not surprising. I'm just frustrated that my company hasn't and doesn't keep tabs on this kinda thing. Even if we did know about this before, who knows how long it would've taken for us to upgrade. I joked with my boss that maybe by 2040 we will be on JDK 17, and I fear that won't be a joke.

The worst part is I need to spent almost 2 hours just to find this thread and figure out what I need to do to fix the issue that failing all of our microservices deployment. I don't understand why search engine or AI/LLM cannot point us to this thread directly.
Mind to make this issue more visible, so people can easily know what to do to fix this?

Yes, it was 100% intentional, and none of the images referenced here should be used (and this is one of the only ways we have to explicitly signal that -- they've all been dead and deprecated and unmaintained for 3+ years).

Copying my note from docker-library/official-images#20210 (comment):

My personal suggestions for users affected by this removal, in decreasing order of suggested precedence:

switch to hub.docker.com/_/eclipse-temurin (it's literally plain compiled builds of OpenJDK for this exact intent, created and maintained by some of the very folks who maintain OpenJDK, and is actively supported/maintained, unlike almost all tags of the openjdk image)

switch to a more specific/explicit/known-outdated tag (openjdk:8u342-jre, for example)

build your own image

In other words, if you want to continue using images from the openjdk repository on Docker Hub, I want to make sure it is very clear to you that the builds you are using are not actively supported or maintained in any way.

Next time you should announce breaking changes since many projects use openjdk docker images and waking up to find that the images are no-longer available is scary. You can at least announce and say that we are removing some images from the registry and the list of images being removed so that companies and projects prepare themselves to migrate or do any changes in their projects. This is not how deprecations are done without the involvement of the affected projects and other stakeholders.

It caught me off guard as well, but as anonymous users of these freely available images, we cannot expect maintainers to liaise with us through some hand written letters about our upgrade plans. It's on us to keep our dependencies in check and 3y is plenty lead time to migrate!

I mean a blog. A simple blog would have worked.

You can still pull the old images; you just have to use an explicit version (though we don't recommend it since they are very outdated): #550 (comment).

And once you resolve the tag to digest, you can pull by digest instead (which will continue to work regardless of any tag changes or deletions):

$ docker pull openjdk:8u342
8u342: Pulling from library/openjdk
8754a66e0050: Pull complete
2068746827ec: Pull complete
d85151f15b66: Pull complete
52a8c426d30b: Pull complete
001c52e26ad5: Pull complete
9daef329d350: Pull complete
d9d4b9b6e964: Pull complete
Digest: sha256:86e863cc57215cfb181bd319736d0baf625fe8f150577f9eb58bd937f5452cb8
Status: Downloaded newer image for openjdk:8u342
docker.io/library/openjdk:8u342
$ docker pull openjdk@sha256:86e863cc57215cfb181bd319736d0baf625fe8f150577f9eb58bd937f5452cb8
docker.io/library/openjdk@sha256:86e863cc57215cfb181bd319736d0baf625fe8f150577f9eb58bd937f5452cb8: Pulling from library/openjdk
Digest: sha256:86e863cc57215cfb181bd319736d0baf625fe8f150577f9eb58bd937f5452cb8
Status: Image is up to date for openjdk@sha256:86e863cc57215cfb181bd319736d0baf625fe8f150577f9eb58bd937f5452cb8
docker.io/library/openjdk@sha256:86e863cc57215cfb181bd319736d0baf625fe8f150577f9eb58bd937f5452cb8

We announced the changes in the only way we ever announce changes - here, in the GitHub PR that made the change (#550) and in the downstream PR that did the most recent openjdk image update (docker-library/official-images#20210). We also took care to not do the change on a Friday afternoon/evening.

@yosifkit

@yosifkit
If I am using openjdk:21 in projects Dockerfile, would we be good to keep it as is while we work with internal teams to upgrade or refer to a different version?

Thank you in advance.

The only JDK 21 we had here was the early access releases. We removed the plain 21 tags because they look like a real GA release when that isn't true of the images. They are still available as openjdk:21-ea or 21-ea-34 to be more specific. To get a supported release beyond the final early access preview that we have here, you'd need to use one of the other images that provide a JDK listed in the deprecation notice: https://hub.docker.com/_/openjdk#deprecation-notice. If you need help picking one, https://whichjdk.com/ is super useful for understanding each of them.

This also applies to every version 19+.

And that's the reason why you use not obscure "openjdk" maintained by a person, not affiliated with a vendor, but images from actual vendors. I work at Bellsoft, so I advocate for our images, but of course, you are free to use others, too. AT least there are guarantees and, in the case of Bellsoft, a chat where you can ask a question like "where's my tag???"

same issue openjdk:17-jdk-slim not found

@wookie3739

same issue openjdk:17-jdk-slim not found

@wookie3739 As stated above you have three possible solutions (ordered from most to least in terms of my preference)

Switch to another base image such as the one provided by Eclipse Temurin. In your case you would use eclipse_temurin:17 (Temurin doesn't seem to have any slim images, but they do have Alpine Linux images)
Find a vendor who distributes OpenJDK images and open a communications channel between you and them, for a price. (I'm assuming you have to sign a contract with them but correct me if I'm wrong)
Use an explicit version as stated above here: docker.io/library/openjdk:24 Not found #551 (comment)

Closing this issue now as above should explain everything.

Navigation Menu

Repository navigation

docker.io/library/openjdk:24 Not found #551

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

docker.io/library/openjdk:24 Not found #551

Description

Activity

vinifsouza commented on Nov 4, 2025

arhor commented on Nov 4, 2025

timothy-mugo commented on Nov 4, 2025

MihFig commented on Nov 4, 2025

ChechuEbury commented on Nov 4, 2025

gayatritrux commented on Nov 4, 2025

guitarfish commented on Nov 4, 2025

BartoszDabek commented on Nov 4, 2025

Eduardnol commented on Nov 4, 2025

rmeyer20 commented on Nov 4, 2025

komodin commented on Nov 4, 2025

akanola commented on Nov 4, 2025

marcus2vinicius commented on Nov 4, 2025

tianon commented on Nov 4, 2025

faizjamil commented on Nov 4, 2025

tianon commented on Nov 4, 2025

faizjamil commented on Nov 4, 2025

bananalemonmelon commented on Nov 5, 2025

timothy-mugo commented on Nov 5, 2025

alexJunger commented on Nov 5, 2025

timothy-mugo commented on Nov 5, 2025

yosifkit commented on Nov 5, 2025

tianon commented on Nov 5, 2025

vnagir commented on Nov 5, 2025

yosifkit commented on Nov 5, 2025

asm0dey commented on Nov 7, 2025

wookie3739 commented on Nov 9, 2025

faizjamil commented on Nov 10, 2025

rmeyer20 commented on Nov 10, 2025

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions