Java LTS Versions and End-of-Life Dates by Vendor

As of 31 October 2026 the Java LTS releases are 8, 11, 17, 21 and 25, and Oracle's roadmap lists the next planned LTS as Java 29 in September 2027. There is no single end-of-life date for any of them: Oracle, Eclipse Temurin, Amazon Corretto, Red Hat, Microsoft and Azul each publish their own, and the dates differ by years. This guide lines them up, with sources. If you are weighing vendors or leaving Oracle Java SE, AceMQ's Java licensing exit and OpenJDK migration help covers that decision.

Java 8 (March 2014), 11 (September 2018), 17 (September 2021), 21 (September 2023) and 25 (September 2025) are long-term support releases. Oracle says it now intends an LTS every two years, which puts Java 29 in September 2027; it marks that designation and its dates as subject to change. Since 2018 Java has shipped a feature release every six months under time-based release versioning, and each non-LTS release is superseded, and stops getting updates, when the next one ships. That is why production systems usually stay on an LTS line.

The table gives each vendor's own published dates, read on 31 October 2026. Temurin's dates are minimums: the project promises at least four years for each LTS. Microsoft's are earliest end-of-support targets that it may extend, and Azul says its dates are minimums. Oracle marks Java 17, 21 and 25 dates as "or later."

Two caveats matter in practice. First, a date is the end of a vendor's updates, not of your risk: a host on an unpatched build stays exposed to every fix released after it. Second, the columns are not interchangeable. Temurin 11 and 17 both end their minimum windows in October 2027, while Corretto 17 runs to October 2029.

For most vendors it is December 2030, but the answer depends on the build. Oracle's Premier Support for Java 8 ended in March 2022 and Extended Support runs to December 2030. Temurin 8 and Corretto 8 both list December 2030, and Azul lists the same for production support. Red Hat is the outlier: full support for its OpenJDK 8 ends on 30 November 2026, with optional paid Extended Life Cycle Support (ELS-1) to 31 December 2032. The Microsoft build has no Java 8 LTS release, and Microsoft says the few Azure services that run Java 8 use Temurin builds.

Applications often decide the date before the JDK does. Spring Boot 3 and later require Java 17, and Apache Kafka 4.0 brokers require Java 17 while its clients need Java 11, so one dependency upgrade can end Java 8 for a service years ahead of the vendor. The framework and server dates are in Spring Boot end of life and Tomcat end of life.

Oracle's roadmap states that Oracle JDK 25 is free for all users under its No-Fee Terms and Conditions license, and that updates released after September 2028 are planned to move to the Java SE OTN license. Oracle JDK 17 updates from 15 October 2024 and 21 updates from 20 October 2026 are under the OTN license, as are Java 8 and 11. OTN permits free use only for personal, development and certain other permitted uses. AceMQ does not give licensing advice, so read your Oracle agreement with your counsel. The version facts above are what that conversation needs.

Pick the version from three constraints, in this order. Start with the framework floor, because Spring Boot 3 and Kafka 4.0 brokers already require 17. Then check the vendor window for the build you will actually run, since the same release has different end dates by vendor. Finally, count the migration cost: moving from 8 to 21 or 25 in one step means one program of work, but every library on the path must support it, and removed Java EE modules, strong encapsulation errors and TLS defaults are where such upgrades stall.

For new services, 21 or 25 gives the longest runway on every vendor in the table. For existing Java 8 estates, an inventory comes first, because most teams find builds they did not know they had.

Ask the runtime, not the directory name. These commands work on Java 8 and later:

The java.vendor property separates Oracle's build from Temurin, Corretto, Microsoft, Red Hat and Azul builds, and the update level shows how far behind the build is. Run the same commands inside container images, because the JDK in a base image is often not the one on the host. For the estate-wide version of this check, see AceMQ's Java inventory and migration service.

A team with a tested build pipeline and a short list of services can run this calendar itself. Help pays off when the estate is large and unmapped, when Java 8 sits under vendor products you cannot change, or when a rollout starts killing containers or breaking TLS handshakes. AceMQ's 24/7 Java support covers the runtime in production on any build, and its Tomcat support covers the application server above it. AceMQ ships no JDK and produces no JDK patches, so security updates still come from your vendor.

Sources (read 31 October 2026): Oracle Java SE Support Roadmap; Eclipse Adoptium support; Amazon Corretto FAQ; Red Hat OpenJDK lifecycle; Microsoft Build of OpenJDK support roadmap; Azul support roadmap; Apache Kafka 4.0 upgrade notes.