Java 8, 11, 17 EOL Dates by OpenJDK Vendor: Temurin to Red Hat

"When does Java 8 reach end of life?" is a trick question. Java 8 does not have one EOL date. It has a dozen, because "Java 8" in production means a specific vendor's build of OpenJDK 8, and every vendor sets its own support timeline. The same goes for Java 11, 17, and 21.

The short answer as of July 2026:

• Red Hat's build of OpenJDK 8 and BellSoft Liberica JDK 8 both end standard support on November 30, 2026. That is the next major Java 8 deadline, four and a half months out. If your RHEL or UBI base images say "OpenJDK 8," this is your date. Both vendors sell paid extensions past it (details in the tables below), but the included window closes in November.
• Eclipse Temurin 8, Amazon Corretto 8, and Azul Zulu 8 run through December 31, 2030.
• Java 11 is already past standard support on some distributions. Red Hat's build ended October 31, 2024, as did Liberica's standard support. Temurin 11 runs until at least October 31, 2027.
• The current LTS is Java 25 (September 2025), with Java 21 and Java 17 still supported everywhere.

This page is the definitive reference for Java runtime EOL dates across distributions. It is updated as vendors revise their timelines. New Relic's 2024 State of the Java Ecosystem report found just under 29% of monitored applications still running Java 8 in production, more than a decade after its release, so these dates matter to a very large installed base.

‍

Why "OpenJDK 8 EOL" Has No Single Answer

OpenJDK is a source-code project, not a binary you deploy. The upstream community maintains the jdk8u and jdk11u update trees, but what you actually run is a vendor's build of that source: Temurin from Eclipse Adoptium, Corretto from Amazon, Zulu from Azul, Oracle JDK, Red Hat's build inside RHEL.

Each vendor ships quarterly security updates (aligned to Oracle's January, April, July, and October Critical Patch Update cycle) for its own window of time. When that window closes, its binaries stop getting patches even if the upstream source tree is still alive. Oracle's free GPL builds at jdk.java.net are the extreme case: they get updates for six months, until the next feature release ships. (Oracle's licensing model is its own maze; see Understanding Oracle Java: Platform, Licensing, and Enterprise Impact.)

So the practical question is never "is Java 8 EOL?" It is "when does my distribution's Java 8 stop getting patches?" The tables below answer that.

‍

Java 8 EOL Dates by Distribution

Java 8 (GA March 2014) is the longest-lived Java release ever, and vendors keep extending it because so much of the enterprise install base sits on it.

(Microsoft's Build of OpenJDK starts at Java 11 and has no Java 8 line.)

The row that matters most is Red Hat's. Its build is the default java-1.8.0-openjdk package on RHEL and the base of countless UBI container images. After November 30, RHEL shops on Java 8 either move to a distribution with a longer window, upgrade the runtime, pay for Red Hat's Extended Life Cycle Support (ELS-1, a separate subscription that carries OpenJDK 8 to the end of 2030), or run unpatched.

What Is Actually Pinned to Java 8

Almost nobody runs Java 8 because they like it. They run it because a framework in the stack requires it, and that framework is often past its own EOL. An unpatched runtime underneath an unpatched framework is the real risk, a pattern we broke down in You're Not Just Running Java 8. You're Running an Entire EOL Stack.

• Spring Boot 2.7 and Spring Framework 5.3 run on Java 8 (through Java 21 on late patch releases), and moving off them means the Boot 3.x jump: a Java 17 baseline plus the javax to jakarta namespace migration. Boot 2.7 has been EOL since June 2023, and its last open-source release carries 143 known CVEs across 79 managed projects. HeroDevs NES for Spring covers Spring Boot 1.5, 2.5, 2.7, 3.2, 3.3, 3.4, and 3.5, along with the matching Spring Framework lines (4.3, 5.3, 6.1, 6.2).
• Apache Struts 1.3, 2.3, and 2.5 predate the modern JDK baseline entirely; surviving Struts estates almost universally sit on Java 8. Struts 1.x has been EOL since 2013 and 2.5 since April 2024, with critical CVEs like CVE-2024-53677 disclosed after EOL. HeroDevs NES for Apache Struts covers Struts 1.x, 2.3, and 2.5, including secured builds that let Struts apps run on Tomcat 10+ and Jetty 11+.
• Apache Tomcat 8.5 requires only Java 7+ and is the servlet container under a huge share of Java 8 workloads. Tomcat 8.5 reached EOL on March 31, 2024 and has picked up dozens of CVEs since, including seven in the May 2026 security release alone. HeroDevs NES for Apache Tomcat provides a secure drop-in replacement for the 8.5 line. For the full container timeline, see the Tomcat versions and EOL dates reference.
• Hibernate ORM 5.6 is the last Hibernate line with a Java 8 baseline; Hibernate 6 requires Java 11. Moving past 5.6 usually triggers the Boot 2.7 to 3.0 chain reaction, which is why so many data layers stay put. CVE-2026-0603 was disclosed against Hibernate 5.6 after upstream support ended. HeroDevs NES for Hibernate is a supported build of the 5.6 artifact tree.

‍

Java 11 EOL Dates by Distribution

Java 11 (GA September 2018) was the first LTS of the six-month release era. A few distributions have already dropped it, which surprises teams who assume "LTS" means "still supported everywhere."

There is a trap here: Red Hat's Java 11 build ended standard support in October 2024. A RHEL shop standardized on Red Hat OpenJDK is already off included support on 11 (patches continue only under the paid ELS-1 subscription, through October 2027) and loses 8 this November. Corretto and Zulu, by contrast, carry Java 11 into 2032 at no cost.

What Is Actually Pinned to Java 11

• Quarkus 2.16 is the final 2.x line and the last major Quarkus generation with a Java 11 baseline. The first LTS, 3.2, also ran on Java 11; the Java 17 floor arrived in Quarkus 3.7, and every current LTS line requires it. The 2.16 line stopped getting community fixes long ago, and Quarkus services sit at the network edge handling HTTP, REST, and auth traffic, which is exactly where unpatched CVEs hurt most. HeroDevs NES for Quarkus is a supported build of the 2.16 line (and 3.20, covered below): a drop-in quarkus-bom swap with no application code changes.
• Grails 6 has a Java 11 baseline and depends on the EOL Spring Boot 2.7. Grails 6.x has been out of support since October 2025. HeroDevs NES for Apache Grails covers Grails 6.2 and 7.
• Spring Boot 2.7 also runs on Java 11, so many "Java 11 estates" are really Boot 2.7 estates with the same EOL math described above.
• Apache Tomcat 10.1 raised the floor to Java 11, which is part of why Tomcat 9 (Java 8 compatible) remains so widely deployed.

‍

Java 17 EOL Dates by Distribution

Java 17 (GA September 2021) is where the modern framework generation starts: Spring Boot 3.x, Quarkus 3.x, and Grails 7 all require it as a minimum.

One Java 17 date lands soon: Oracle JDK 17 premier support ends September 30, 2026.

What Is Actually Pinned to Java 17

• Spring Boot 3.5 and Spring Framework 6.2 have a Java 17 baseline. Spring Boot 3.5 reached end of open-source support in June 2026, and the path forward is Spring Boot 4.0: 83 breaking changes and an estimated 200 to 500 hours of migration work. HeroDevs NES for Spring covers Boot 3.5 (plus 3.2, 3.3, and 3.4), with coverage starting the day OSS support ends. The full lifecycle picture is in the Spring Boot versions and EOL dates reference.
• Quarkus 3.20 is the Java 17 era Quarkus LTS, and each Quarkus LTS line gets roughly a year of active support. HeroDevs NES for Quarkus covers the 3.20 line alongside 2.16.
• Grails 7 is built on the now-EOL Spring Boot 3.5, which puts Grails 7 estates on a clock even though Grails 7 itself is current. HeroDevs NES for Apache Grails covers Grails 7 and 6.2.

‍

Java 21 and Java 25: The Current LTS Lines

For teams planning a landing zone, here is where the two newest LTS releases stand:

Java 25 (September 2025) is the current LTS and the right target for new builds. Java 26 is the current non-LTS feature release and, like every non-LTS release, loses support the moment Java 27 ships. The Java 25 dates above reflect each vendor's published LTS policy as of July 2026; confirm against the vendor's roadmap when you plan, since these are the newest commitments and the most likely to shift.

‍

What Happens When Your JDK Goes EOL

A JDK going EOL is quieter than a framework going EOL, which makes it easier to miss:

1. Quarterly security patches stop. The JDK ships fixes for the JVM, the TLS stack, the crypto providers, and the class libraries every quarter. After EOL, CVEs against those components go unpatched in your binaries.
2. The trust and crypto baseline decays. Root CA updates, TLS protocol changes, and cipher deprecations stop arriving, and old builds gradually lose the ability to talk to modern endpoints cleanly.
3. Scanners flag the runtime, not just the app. Container scanners flag EOL JDK base layers as unsupported software, which lands in the same SOC 2, PCI DSS, HIPAA, FedRAMP, NIS2, DORA, and EU CRA conversations as an EOL framework.
4. Findings compound. An EOL framework on a supported JDK is one open finding. An EOL framework on an EOL JDK is two, and fixing the runtime usually means fixing the framework first (Boot 2.7 cannot follow you to a Java 17 baseline).

‍

Options If You Are on an EOL Java Stack

1. Upgrade the whole stack. The JDK bump is rarely the hard part; the frameworks gate it. Getting off Java 8 means getting off Spring Boot 2.7, Hibernate 5.6, Struts, or Tomcat 8.5 first, and the Boot 2.7 to 3.x move alone involves the Java 17 baseline plus the Jakarta namespace migration across every dependency. Budget for the framework migration and treat the JDK as the last mile.

2. Buy time at the framework layer with NES. If the migration cannot land before your dates hit, HeroDevs Never-Ending Support keeps the framework layer patched and audit-ready on the stack you already run: Spring (Boot 1.5 through 3.5), Apache Struts (1.x, 2.3, 2.5), Apache Tomcat (8.5), Hibernate (5.6), Quarkus (2.16, 3.20), and Apache Grails (6.2, 7). Coverage begins the day OSS support ends, with no gap, and ships with the VEX statements and documented patch history auditors ask for. That turns "we are on an EOL stack" from an open finding into a supported configuration while you migrate on your own schedule.

3. Fix the runtime date alone. If your only problem is the runtime (say, Red Hat OpenJDK 8's November 2026 cutoff), you have two moves. Switching to Temurin 8 or Corretto 8 buys you until the end of 2030 at no license cost, and distribution swaps at the same major version are usually low-drama. Or stay put and pay the incumbent vendor for its extended phase, like Red Hat's ELS-1 subscription. Either way, this solves the runtime finding only; it does nothing for the EOL frameworks running on top of it.

‍

Which JDK Distribution Are You Actually Running?

The dates above only help if you know which vendor's build is in production, and "we run OpenJDK" is not an answer. Start with the runtime itself:

java -version

The vendor is in the output:

If the output is ambiguous, ask the JVM directly:

java -XshowSettings:properties -version 2>&1 | grep -iE 'java\.(vendor|runtime\.name|version)'

On RHEL and its derivatives, the package name settles it. Red Hat's build ships as java-1.8.0-openjdk, java-11-openjdk, and so on:

rpm -qa | grep -iE 'openjdk|temurin|corretto|zulu|liberica'

On Debian and Ubuntu:

dpkg -l | grep -iE 'jdk|jre'

For containerized workloads, check the images rather than the hosts. Run the image's own runtime and grep your Dockerfiles for base images:

docker run --rm --entrypoint java your-image:tag -version
grep -rEl 'FROM .*(jdk|jre|temurin|corretto|zulu|openjdk)' .

And for JVMs already running in an environment you can shell into:

for pid in $(pgrep java); do jcmd $pid VM.system_properties 2>/dev/null | grep -E '^java\.(vendor|version)='; done

Record distribution and major version per service. That inventory is the input for everything in the next two sections.

‍

Quick Reference: Is My Java Version Still Getting Free Updates?

‍

Frequently Asked Questions

Is Java 8 still supported in 2026?

Yes, but the window depends on the distribution. Red Hat's build of OpenJDK 8 and BellSoft Liberica 8 end standard support November 30, 2026, with paid extensions available (Red Hat ELS-1 to December 31, 2030; Liberica extended to March 31, 2031). Eclipse Temurin, Amazon Corretto, and Azul Zulu support Java 8 through December 31, 2030 at no cost.

When does OpenJDK 8 reach end of life?

There is no single date, because "OpenJDK 8" means a vendor's build. The most common enterprise answer is November 30, 2026, when standard support for Red Hat's build of OpenJDK 8 (the default on RHEL) ends; Red Hat's paid ELS-1 phase then runs to the end of 2030. Community builds like Temurin 8 and Corretto 8 continue until December 31, 2030.

Is Java 11 end of life?

On some distributions, standard support has ended. Red Hat's build of OpenJDK 11 and Liberica's standard support both ended October 31, 2024; Red Hat's paid ELS-1 phase for OpenJDK 11 continues to October 31, 2027. Eclipse Temurin 11 is supported until at least October 31, 2027, and Amazon Corretto 11 and Azul Zulu 11 until January 31, 2032.

What is the latest Java LTS version?

Java 25, released in September 2025. Eclipse Temurin supports it until at least September 30, 2031. The prior LTS releases (21, 17, 11, and 8) remain supported on varying schedules per distribution.

Does Java 8 EOL affect Spring Boot 2.7 applications?

They compound. Spring Boot 2.7 reached EOL in June 2023 and runs on Java 8, so a Boot 2.7 app on Red Hat OpenJDK 8 loses standard runtime patches in November 2026 on top of the framework patches it already stopped receiving. Upgrading the JDK requires Boot 3.x (Java 17 baseline), so teams either migrate the framework or adopt NES for Spring to keep the Boot 2.7 layer patched while they plan.

‍

Taking Action

Pull your JDK inventory this week using the commands above: distribution and major version, per service. Circle anything on Red Hat OpenJDK 8 or Liberica 8 standard (both November 30, 2026), or an already-EOL Java 11 build. Then map which frameworks pin each runtime in place, because that mapping, not the JDK itself, sets your real migration cost.

If the frameworks holding you on an EOL Java stack are Spring Boot, Struts, Tomcat, Hibernate, Quarkus, or Grails, talk to HeroDevs about keeping that layer secure while you migrate on your own timeline.