Java End of Life Versions: Support Dates and Upgrades

Java has no single end of life date: each LTS release ends when the distribution you run stops shipping quarterly security updates for it, and those dates differ by years between suppliers. A team on Java 8 may be fully covered by one build and running unpatched code on another, with the same java -version output. This guide gives the official support dates for Java 8, 11, 17, 21 and 25 across six widely used distributions, explains how licence terms change during a release's life, and shows how to find every Java runtime in servers, container images, bundled software and build pipelines, then how to plan, test and roll back an upgrade. It is for vulnerability management, platform and application security teams. For the cross-language view see the End-of-Life Language Runtimes guide; this page goes deeper on Java only. Distributions are listed alphabetically throughout, and order is never a ranking.

Key takeaways

Support depends on the build, not the version number. Java 8, 11, 17, 21 and 25 are all LTS releases, but each supplier publishes its own end date, so record the vendor alongside the version in your inventory.
Java 17 is the release to watch now. Oracle Premier Support for Oracle JDK 17 runs to September 2026 (or later), and Eclipse Temurin and the Microsoft Build of OpenJDK both list September or October 2027 as their earliest end for 17.
Licence terms move during a release's life. Oracle moved Oracle JDK 17 updates released from 15 October 2024, and Oracle JDK 21 updates released from 20 October 2026, from no-fee terms to the Java SE OTN licence, which changes who may use those updates for free.
Every quarter matters. Java security fixes ship on a quarterly cycle (Oracle's Critical Patch Updates fall on the third Tuesday of January, April, July and October), so a supported release that is two quarters behind is still exposed.
Containers and bundled runtimes hide old Java. The deprecated openjdk Docker image, vendor appliances with an embedded JRE and fat JARs built for class file version 52 keep Java 8 alive long after the estate policy says it is gone.

How Java support works

OpenJDK is the open-source reference implementation of Java SE. A new feature release ships every six months, in March and September, and some releases are designated long-term support (LTS). Oracle states that it intends to make LTS releases every two years; Java 8, 11, 17, 21 and 25 are LTS, and Oracle's roadmap names Java 29 (September 2027) as the next planned LTS, while marking the designations and dates for 27 to 29 as subject to change. Non-LTS releases, such as Java 26 (March 2026), are superseded as soon as the next feature release is available. Oracle lists Premier Support for Oracle JDK 26 only to September 2026.

Distributions take the OpenJDK source, build and test it, and publish quarterly update releases. Each distributor decides how long it will keep shipping updates for an LTS line and whether those updates are free. The practical meaning of "Java 11 end of life" therefore has three parts:

Supplier: whose binaries you run (the java.vendor property and the IMPLEMENTOR line in the JDK's release file).
Support phase: free public updates, paid commercial support, or paid extended support, each with its own end date.
Update level: whether you have applied the latest quarterly update for that line. Microsoft, for example, states that to receive commercial support a system must stay on the latest update within a release's support lifecycle.

Official support dates by distribution

Dates below are taken from each supplier's own roadmap page, checked on 13 November 2026. Suppliers publish month and year rather than exact days, several describe their dates as minimums or initial targets, and all can change. Confirm against the linked roadmap before making a decision.

Distribution (support phase shown)	Java 8	Java 11	Java 17	Java 21	Java 25
Amazon Corretto (end of life; last planned update one quarter earlier)	December 2030	January 2032	October 2029	October 2030	October 2032
Azul Core and Azul Prime (end of Production Support)	December 2030	January 2032	September 2029	September 2031	September 2033
Eclipse Temurin (end of availability, "at least")	December 2030	October 2027	October 2027	December 2029	September 2031
Microsoft Build of OpenJDK (earliest end of support)	Temurin builds used (see note)	September 2027	September 2027	September 2028	September 2030
Oracle JDK (Premier Support)	March 2022	September 2023	September 2026 (or later)	September 2028 (or later)	September 2030 (or later)
Oracle JDK (Extended Support)	December 2030	January 2032	September 2029 (or later)	September 2031 (or later)	September 2033 (or later)
Red Hat build of OpenJDK (end of full support)	30 November 2026	31 October 2024	31 December 2027	31 December 2029	31 December 2030
Red Hat build of OpenJDK (end of ELS-1)	31 December 2032	31 January 2032	31 January 2029	30 September 2031	30 September 2033

Availability notes

Amazon Corretto: Amazon describes Corretto as distributed under an open-source licence at no cost, with long-term support, including security updates, at no cost until end of life. Updates are planned quarterly, with urgent fixes released outside the cycle when ready.
Azul: the dates are for Azul's commercial Production Support for Azul Core and Azul Prime. Azul states that LTS releases get a further two years of Extended Support after those dates.
Eclipse Temurin: the Adoptium project lists end of availability as a minimum; support may continue while the upstream OpenJDK update project remains actively maintained.
Microsoft Build of OpenJDK: quarterly updates (January, April, July, October) are free to anyone; commercial support follows Microsoft's Modern Lifecycle Policy and the dates are described as initial targets that Microsoft may extend. For Java 8 on Azure services and in containers, Microsoft's documentation directs customers to Eclipse Temurin builds, including Temurin-based OpenJDK 8 images on the Microsoft Container Registry.
Oracle JDK: the dates apply to commercially supported Oracle JDK for Oracle customers; Sustaining Support is indefinite but does not deliver new fixes in the way Premier and Extended Support do. Oracle JDK 8 public updates remain free for personal, development and some other uses; Oracle JDK 11 is under the Java SE OTN licence; Oracle JDK 25 has been under the Oracle No-Fee Terms and Conditions since September 2025, with updates after September 2028 planned under the OTN licence.
Red Hat build of OpenJDK: Red Hat lists the same dates for RHEL and Windows; the ELS-1 phase requires a separate paid Extended Life Cycle Support subscription, and Red Hat's lifecycle article notes that OpenJDK 8 on RHEL 9 is supported to the date shown.

Who and what is affected

Most Java estates are larger than the application portfolio suggests. Typical places an out-of-support runtime survives:

Location	Why it is missed	Where to look
Server installs	Installed once by hand or by an old configuration management role, then never upgraded	Package manager inventory, `/usr/lib/jvm`, `C:\Program Files\Java`, `alternatives` links
Container base images	A pinned tag keeps shipping the same old runtime on every rebuild	Dockerfile `FROM` lines, the image's `JAVA_VERSION` environment variable, image SBOMs
Deprecated `openjdk` images	Docker Hub marks the official `openjdk` image as deprecated, with regular updates ending around July 2022, yet old tags still pull	Registry scans for `openjdk:` references in Dockerfiles, Helm charts and CI templates
Bundled and embedded runtimes	Vendor appliances, middleware, IDEs, build tools and desktop software ship a private JRE that system patching does not touch	File system search for `release` files and `bin/java` outside standard paths; vendor support matrices
Serverless and PaaS runtimes	The platform's managed runtime version is set per function or app and outlives the original project	Cloud provider runtime settings per function and per app service
Build pipelines	CI runners and build images compile with an old JDK or target an old bytecode level	Maven `maven.compiler.release`, Gradle toolchains, CI runner images
Desktop clients	Legacy thick clients and applets-era tools pin a JRE on user devices	Endpoint software inventory, browser and client support documents

Finding affected systems and identities

Inventory first, then classify by vendor, line and update level. These checks are read-only and safe to run at scale through your existing endpoint or configuration tooling.

Read the runtime's own metadata. Every modern JDK and JRE home contains a release text file with JAVA_VERSION, IMPLEMENTOR and often JAVA_RUNTIME_VERSION. Collecting this file from every java binary found on disk gives version and vendor without starting the JVM.
Read running JVMs. Process inventory shows the path of every running java binary; map each to its release file. Application monitoring agents usually also report java.version and java.vendor.
Scan images, not just hosts. Generate an SBOM for every container image in your registries and query it for JDK and JRE packages. Search Dockerfiles and templates for openjdk:, :8-, :11- and similar pinned tags. See the Container Image Vulnerability Management Guide.
Check the bytecode target. The class file major_version shows the oldest Java an artifact was built for: 52 for Java 8, 55 for 11, 61 for 17, 65 for 21 and 69 for 25. JARs at 52 are not a vulnerability in themselves, but they show which applications were never rebuilt and may depend on removed APIs.
Check build configuration. Query repositories for maven.compiler.source, maven.compiler.release, Gradle toolchain settings and CI images. This finds the pipelines that will rebuild old runtimes tomorrow.
Classify each finding. Record vendor, line, update level and the support phase you are entitled to. A Java 8 runtime from a vendor whose free updates continue to 2030 is a patch currency question; the same version from a supplier whose support has ended is an end of life finding.

Where identity fits: Java services frequently run as service accounts with database, message broker and API credentials, and the runtime holds keys and trust anchors in keystores. An old JDK can carry an outdated cacerts trust store and legacy keystore formats, and an upgrade can change which algorithms are allowed. Treat the service account, its secrets and its keystores as part of the upgrade scope. See the Java Keystores Guide.

Migration options

Option	When it fits	Trade-offs
Upgrade to the newest LTS (Java 25)	Maintained applications with active owners and tests	Most code change up front; longest runway, with supplier dates out to 2030 and beyond
Upgrade to Java 21	Applications whose frameworks or vendors do not yet certify 25	Smaller jump from 17; plan the next move before 21's supplier dates arrive
Stay on the same line, change distribution	Stable applications on 8 or 11 where a supplier still ships updates	No code change, but you still carry an old platform; licence and support terms must be confirmed in writing
Buy extended support from your current supplier	Short bridge while a migration completes	Cost and contract dependency; set an exit date when you buy
Retire or replace the application	Low-value or vendor-abandoned software	Business change effort, but removes the runtime entirely
Isolate and accept the risk	Last resort for systems that cannot change yet	Requires compensating controls, a named risk owner and a review date

Framework baselines drive the decision. Check what your frameworks require before choosing a target. For example, the Spring Boot 4.1.2 system requirements state a minimum of Java 17 and compatibility up to and including Java 27, so a Java 8 or 11 application on an old Spring Boot line needs a framework upgrade as well as a runtime upgrade. See the Java and Spring Security Guide.

Small and large organisations. A small team with a handful of services usually does best standardising on one free distribution and one LTS, and upgrading everything in one programme. A large estate typically needs a supported-runtime catalogue (approved distributions, lines and base images), a waiver process with expiry dates, and per-application upgrade waves ordered by internet exposure.

Testing and rollback

Build on the target JDK first. Compile with the new JDK while still targeting the old release, fix warnings, then raise the target. Run the full test suite on the new runtime in CI.
Check removed and encapsulated APIs. The JDK's jdeps tool reports dependencies on JDK internal APIs; libraries that used them are a common cause of failures after Java 8. Update those libraries before the runtime.
Test TLS and cryptography. Newer JDK updates disable legacy protocols and algorithms through the java.security file. Test outbound connections to partners, databases and legacy endpoints, and do not re-enable disabled algorithms as a shortcut.
Compare runtime behaviour. Garbage collector defaults, memory settings and container awareness differ between lines. Load test and compare heap, latency and start-up metrics before production.
Roll out in rings. Start with non-production, then a canary instance or a small share of traffic, then the rest. Keep the previous image tag or package available and documented as the rollback, and set a date after which rollback is no longer allowed so the old runtime is actually removed.

Risks of doing nothing

Unfixed vulnerabilities: once a supplier stops shipping updates for a line, vulnerabilities fixed in later quarterly updates stay open on your runtime. Internet-facing Java services are then exposed to exploitation of public-facing applications (ATT&CK T1190), and Java desktop clients to exploitation for client execution (T1203).
Licence exposure: applying an update released under different terms (for example Oracle JDK 17 updates from 15 October 2024 under the OTN licence) can create an unplanned commercial obligation. Track the licence of each update, not just the version.
Framework lock-in: current framework releases set Java baselines, so an old runtime also blocks security fixes in the libraries on top of it.
Audit findings: NIST SP 800-53 SA-22 (Unsupported System Components) expects unsupported components to be replaced, or covered by justified alternative support, so an out-of-support runtime is a likely audit finding.

Detection and measurement

Coverage: share of hosts, images and functions with a recorded Java vendor, line and update level (target: all).
Out-of-support count: number of runtimes past their supplier's end date, trended monthly toward zero.
Patch currency: share of Java runtimes on the latest quarterly update within 30 days of release.
Old bytecode: number of production artifacts still at class file version 52 or 55.
Waiver age: count and age of risk acceptances for out-of-support Java, with none past their review date.

Framework mapping

Framework	Reference	How it applies
NIST SP 800-53 Rev 5	SA-22 Unsupported System Components	Replace out-of-support Java or document alternative support
NIST SP 800-53 Rev 5	CM-8 System Component Inventory	Record every runtime with vendor and version
NIST SP 800-53 Rev 5	SI-2 Flaw Remediation; RA-5 Vulnerability Monitoring and Scanning	Apply quarterly updates; scan hosts and images for outdated JDKs
NIST CSF 2.0	ID.AM-02, ID.RA-01, PR.PS-02	Software inventory, vulnerability identification, and maintaining or replacing software commensurate with risk
CIS Controls v8.1	Control 2 Inventory and Control of Software Assets; Control 7 Continuous Vulnerability Management	Authorised, supported software only; patch on a defined cycle. See the CIS Control 7 Continuous Vulnerability Management Guide.

Common failure patterns

Tracking version without vendor. A report that says "Java 11: supported" is meaningless; Red Hat's full support for OpenJDK 11 ended on 31 October 2024 while other suppliers continue to 2027 or 2032.
Trusting a supported line that is not patched. A supported release left on an update from a year ago carries four quarters of known fixes.
Pinned base images. Rebuilding from openjdk:8 or another frozen tag every night creates new images with an old runtime.
Forgetting embedded runtimes. Appliances and commercial software with a private JRE are outside system patching; their vendor's support statement is the only route to fixes.
Re-enabling legacy crypto to get the upgrade through. Editing java.security to allow disabled algorithms swaps a runtime risk for a cryptographic one.
Treating extended support as the plan. Paid extended support without a dated exit becomes permanent.

Practitioner checklist

Inventory every Java runtime with vendor, line, update level and owner, including images, functions and embedded JREs.
Record each supplier's support end date and licence terms from its roadmap page, and review them each quarter.
Publish an approved list of distributions, LTS lines and base images; block deprecated openjdk images in CI.
Apply quarterly updates within a defined window after each release.
Prioritise internet-facing services on out-of-support lines for the first upgrade wave.
Check framework Java baselines and upgrade frameworks with the runtime.
Include service accounts, secrets, keystores and trust stores in upgrade testing.
Test with jdeps, CI builds and load tests, roll out in rings, and keep a dated rollback.
Give every exception a named owner, compensating controls and an expiry date.

Java End of Life Versions: Support Dates by Distribution and How to Upgrade