The openjdk Docker image is deprecated, and only its Early Access tags still move

The README opens with the word DEPRECATED

The first line of the file is a heading reading DEPRECATED, and that is the entire message in front of the technical documentation. The notice says the image is officially deprecated and all users are recommended to find and use suitable replacements ASAP, and it adds a caveat that the examples are listed in alphabetical order with no intentional or implied preference.

That caveat matters more than it first appears. The list contains five other Docker Official Images: amazoncorretto, eclipse-temurin, ibm-semeru-runtimes, ibmjava and sapmachine. None of them is a drop-in replacement for a specific build, they are vendors' own distributions of OpenJDK packaged by the Docker community, and the README is careful not to steer you toward one of them.

So the practical reading is that the decision has been delegated to you, on the grounds that the choice of JDK vendor is an organisational decision rather than a packaging one. A team that already standardises on a particular distribution should use that vendor's image, and a team that has no standard should evaluate the list against its own constraints.

Behind the notice, the rest of the README is the standard Docker Official Image boilerplate. This is the Git repo of the Official Image for openjdk, not to be confused with any official openjdk image provided by openjdk upstream, and it is maintained by the Docker Community.

Early Access tags are the only part of the image that still updates

The deprecation has a carve-out, and it is stated precisely. The only tags which will continue to receive updates beyond July 2022 will be Early Access builds, which are sourced from jdk.java.net, and the reason given is that those are not published or supported by any of the replacement projects listed in the notice.

This is the one genuinely useful fact in the file for a reader deciding what to do. If you need a specific early build of a JDK, for example to test behaviour before a general availability release, the alternative images will not carry it, and this image still does. If you need a released, supported JDK, then this image is a dead end and the five alternatives are the live options.

The date is worth noticing too. The cut-off was July 2022, and the repository has continued to take commits since, with the last push on 2026-10-15. Those commits are the Early Access line being refreshed, and the mechanism for that is visible in the tree, where a versions.sh script and a versions.json file sit alongside the update and apply-templates scripts.

So this repository is in a strange but coherent state: the product is retired, the source is still maintained, and the only thing still moving through it is the one thing nobody else publishes. That is a deliberate and defensible arrangement, and it is the opposite of an abandoned repository.

The real source of truth for the tag list is another repository

If you want to know which tags currently exist for this image, the README does not list them, and the answer is somewhere else. The README points to the library/openjdk file in the official-images repository as the current source of truth for openjdk, and it also points to the PRs with the library/openjdk label on the official-images repository for outstanding image pull requests.

The split is the standard Docker Official Images arrangement. The source lives in this repository, the full image description including the usage documentation is generated and maintained in the docker-library/docs repository, specifically in the openjdk directory, and the Docker Hub page for openjdk is where the user-facing readme lives. The README in this repository is a stub, and it says so, ending with a comment that the file is generated by the generate-repo-stub-readme.sh script in the docs repository.

There is also a separate FAQ entry about what happens when a change is merged in Git but does not show up on Docker Hub yet, and that link is the one to read if you are waiting for a tag to appear after a build.

For a reader doing due diligence on the alternatives, the same structure applies to them, which means you can compare the deprecation status and the update policy of amazoncorretto, eclipse-temurin and the rest by looking at their own repositories and their entries in the official-images repository.

The Dockerfiles are generated from templates, not maintained by hand

The repository layout shows that this is a generator rather than a directory of hand-written Dockerfiles. The top-level entries include the two platform templates, the scripts and the metadata files.

Dockerfile-linux.template
Dockerfile-windows.template
apply-templates.sh
update.sh
versions.sh
versions.json

There is also a version directory named 28, a shared.jq file, and a pair of scripts for generating the stackbrew library, generate-stackbrew-library.sh and generate-stackbrew-library.jq.

Based on that layout, the build works by templating: a per-version directory holds the content for a JDK release, the templates add the platform-specific parts, and the scripts render the result and update the version metadata. The 28 directory is the container for one JDK major version, and the linux and windows templates are the two platform variants that get rendered from it.

The presence of both a Linux and a Windows template is worth noting, because it is one of the reasons this image is not interchangeable with a generic Linux-only JDK image. A build that currently relies on the Windows variant of the openjdk image has to find a replacement that also publishes Windows tags, and that is a concrete question to ask before migrating rather than a detail to discover afterwards.

The jq files are there because the metadata is processed as JSON, which is how the version list and the generated library file stay in sync with what the build scripts produce.

MIT licensed, and the community still owns the repository

The licence is MIT, and the LICENSE file is at the repository root. The code in this repository, meaning the templates and the build scripts, can be used, modified and redistributed provided the copyright notice and the licence text are kept. This is a licensing fact rather than legal advice, and it is worth separating clearly from the licensing of the JDK binaries the image downloads, which carry Oracle's own terms for the OpenJDK builds that Oracle publishes and the respective vendors' terms for the distributions in the replacement images.

The maintainership is the other thing the README makes explicit. It is maintained by the Docker Community, which is the group behind the Official Images programme, rather than by Oracle. That is why the deprecation is phrased as a community decision with a list of alternatives rather than a vendor announcement, and it is why the repository accepts pull requests through the official-images repository's label instead of directly.

Activity continues. The repository is not archived, the default branch is master, and the last push was on 2026-10-15, with no GitHub releases because the artefacts are the container tags rather than release binaries. For a reader deciding how much to trust the Early Access line, the relevant question is whether that cadence is enough for your needs, and the honest answer is that it is a community-maintained refresh of upstream nightly-style builds rather than a vendor-supported release channel.

What the deprecated image was, and why the alternatives are a different shape

The package description tells you what this repository produced: Docker Official Image packaging for EA builds of OpenJDK from Oracle, and the primary language recorded for the repository is Dockerfile, which fits a template-driven image build.

The alternatives are a different shape of thing, and it helps to be clear about that rather than treating the swap as a like-for-like change. Each of the five listed images packages a vendor's own distribution of OpenJDK rather than Oracle's own build stream, so what you are choosing between is a packaging convention and a support commitment, not a set of interchangeable files. The vendor images are maintained by the same Docker Official Images machinery and follow the same conventions, which is why the deprecation notice can point at them without qualification.

The one capability that does not transfer is the Early Access stream, because those builds come from jdk.java.net and are not published or supported by any of the replacement projects. That is why the notice carves them out rather than retiring them, and it is the single fact that decides whether you can move away from this image today or whether you have to wait for your early-build requirement to end.

For a team whose builds are reproducible from released JDKs, the migration is a matter of changing the base image reference and confirming the tags line up with the JDK versions you need. For a team tracking early builds, the image is still the only source, and the deprecation notice says so plainly rather than pretending otherwise.

Editorial conclusion

The openjdk Official Image is the right choice only if you specifically need an Early Access build of OpenJDK, since that is the one line no alternative publishes and the one that still receives updates past July 2022. For anything else, the image is retired, its tags will stop moving, and one of the five listed replacements will serve better. Before you migrate, check the library/openjdk file in the official-images repository, which is the stated source of truth for the tag list, and confirm that the replacement image you pick covers the JDK versions and the platform your build needs, including Windows if you relied on the windows template.

Frequently asked questions

Official sources

1. docker-library/openjdk on GitHub
2. Issues
3. License: MIT
4. Project website
5. README