There is no single Java 8 end of life date. It depends on whose build of Java you run and what contract you have. Red Hat's build of OpenJDK 8 leaves full support on 30 November 2026, while Oracle's Extended Support, Amazon Corretto 8, IBM Semeru 8 and Azul's Java 8 support all run to December 2030.
People repeat one date as if it covered everyone. This post sets out the end dates each vendor publishes for Java 8, 11, 17 and 21, what each means, and how to find out which Java your applications really run.
- Java 8 has no single end of life date. Each vendor that builds Java publishes its own, and your contract decides which applies.
- Red Hat's build of OpenJDK 8 leaves full support on 30 November 2026. Oracle, Amazon, IBM and Azul list December 2030 for Java 8.
- Oracle's Java 8 dates apply to Oracle customers with a support contract. Commercial use of new Oracle Java 8 updates needs one.
- Before you plan around any date, find out which vendor's Java each application actually runs.
Is Java 8 end of life?
Not everywhere, but it's close for some builds. Java is open source (the OpenJDK project), and several vendors build and patch their own distributions. Each decides how long it patches each version, so "Java 8 end of life" is really six or more separate dates.
Oracle's own Premier Support for Java 8 ended in March 2022. Oracle customers stay on Extended Support until December 2030, and Oracle's roadmap says the Extended Support uplift fee is waived for Java 8 for that whole period. Red Hat's full support for its OpenJDK 8 build ends next month. Everyone else listed below runs to December 2030.
Java 8 end of life date, by vendor and version
Each cell is the end date the vendor publishes. Where a vendor offers two support levels, both are shown.
| Vendor and build | Java 8 | Java 11 | Java 17 | Java 21 |
|---|---|---|---|---|
| Oracle JDK, Premier Support | Ended March 2022 | Ended September 2023 | September 2026 | September 2028 |
| Oracle JDK, Extended Support | December 2030 | January 2032 | September 2029 | September 2031 |
| Red Hat build of OpenJDK, full support | 30 November 2026 | Ended 31 October 2024 | 31 December 2027 | 31 December 2029 |
| Red Hat build of OpenJDK, ELS-1 (paid add-on) | 31 December 2032 | 31 January 2032 | 31 January 2029 | 30 September 2031 |
| Eclipse Temurin (Adoptium) | At least December 2030 | At least October 2027 | At least October 2027 | At least December 2029 |
| Amazon Corretto, end of life | December 2030 | January 2032 | October 2029 | October 2030 |
| IBM Semeru Runtimes, end of availability | 31 December 2030 | 31 October 2027 | 31 October 2027 | 31 December 2029 |
| IBM SDK, Java Technology Edition 8 | 31 December 2030 | Not applicable | Not applicable | Not applicable |
| Azul Zulu (Azul Core), end of Production Support | December 2030 | January 2032 | September 2029 | September 2031 |
Checked 27 October 2026 against Oracle's Java SE Support Roadmap (updated 20 October 2026), Red Hat's OpenJDK life cycle and support policy, Adoptium's Temurin support page, the Amazon Corretto FAQs, IBM's Semeru Runtimes support page, IBM's Java SDK lifecycle dates and Azul's support roadmap.
What each vendor's date actually means
The dates don't all measure the same thing, so read the label first.
Oracle. The roadmap says its dates "apply only to the commercially supported Oracle JDK releases available to Oracle Customers," and marks the Java 17 and 21 dates "or later." Since the 16 April 2019 critical patch update, Oracle customers get Java 8 updates for commercial use through My Oracle Support. Oracle JDK 8, 11, 17 and 21 updates sit under the OTN license, which allows personal and development use at no cost. Java 25 is under Oracle's No-Fee Terms and Conditions, with updates after September 2028 planned to move to OTN.
Red Hat. "Full support" is the standard phase. ELS-1 is, in Red Hat's words, "an optional, paid extension, requiring a separate ELS subscription." For anyone asking about the Red Hat Java 8 end of life, 30 November 2026 is the date that applies without that subscription.
Eclipse Temurin. Adoptium's dates are minimums ("at least"). Its page says Adoptium builds LTS binaries "as long as the corresponding upstream source is actively maintained," so the Temurin Java 8 end of life could move later than the date shown.
Amazon Corretto. Amazon lists a last planned update and a later end of life. For Corretto Java 17 end of life, the last planned update is July 2029 and end of life is October 2029.
IBM. IBM ships two Java 8 lines: Semeru Runtimes and the older IBM SDK, Java Technology Edition. For the IBM Java 8 end of life, IBM says the SDK "will continue to receive security updates" until 31 December 2030. IBM also warns that when Semeru is built into an IBM or vendor product, "EOS dates might differ from those in the table."
Azul. Azul's dates mark the end of the Production Support term. For the Zulu Java 11 end of life, that's January 2032, and Azul says to "add an additional 2 years for Extended Support for LTS releases."
How do you find out which Java you actually run?
Ask each machine, not the documentation.
- Run
java -version. It prints the version and the runtime name. Java 8 reports itself as1.8.0plus an update number; from Java 9 the leading "1" was dropped (JEP 223). The runtime line often names the vendor's build. - Print the vendor properties. Run
java -XshowSettings:properties -versionand readjava.vendor,java.vm.vendorandjava.home. Oracle's System properties reference definesjava.vendoras the "Java Runtime Environment vendor." - Check more than the default. The
javaon the PATH may not be the one your application uses. CheckJAVA_HOMEand startup scripts. - Look inside containers. An image carries its own Java from its base image, whatever the host runs.
- Look inside products. Application servers, vendor packages and desktop tools often bundle their own Java. Oracle notes that "timelines may differ for Oracle Products with a Java SE dependency," and IBM says the same of its products.
Write the results down per application: version, vendor, where it came from, and which date from the table applies.
What changes when your Java build reaches its date
Nothing switches off. What stops is security patches for that build, so known vulnerabilities stay in place for good. We cover what that means for audits and insurers in the risks of running end-of-life software.
Moving to a later Java is rarely a runtime swap. Code written for Java 8 can break on 17, and the steps are in our Java 8 to 17 migration guide. Frameworks set their own floor too: Spring Boot 3 requires Java 17, which is why Spring Boot 2 end of life and Java 8 usually turn into one project. Old Java applications turn up on most lists of legacy system examples for exactly this reason.
When the question is bigger than the runtime
Changing the Java version is the easy half. The hard half is knowing what depends on the old one, and that's where the 30-day assessment fits. It's fixed in scope, at a price agreed before we start. Over 30 days we read the codebase and the architecture around it, map how the application fits together with what it calls and what calls it, find the hidden architectural debt, and flag the security and compliance gaps, including every runtime and library past its vendor's date.
The report says in plain language what is broken and what it would take to fix it. Your own team can act on it, or we can do the work as a separate project with its own scope and price. Either way, the report stands on its own.
Ask us whether it's worth assessing before you commit to a Java upgrade plan.