Java 8 end of life
Java 8 is a special case: there is no single end-of-life date. Oracle ended free public updates for commercial use in January 2019, but OpenJDK 8 is still actively maintained by several distributors — Eclipse Temurin, Amazon Corretto, Azul Zulu and Red Hat all continue to ship 8u security updates, and Oracle's own extended support runs to at least 2030. So Java 8 is unsupported if you are on Oracle JDK without a contract, and supported if you are on a maintained OpenJDK build.
- End of life
- January 2019 (Oracle public updates for commercial use)
- Released
- Mar 2014
- Final release
- varies by distribution — Temurin, Corretto and Zulu all still ship 8u updates
- Successor
- Java 17 or Java 21 (both LTS)
Date published by Oracle Java SE support roadmap. We do not publish a lifecycle date we cannot source.
What actually stops on January 2019
- Oracle JDK 8 free public updates for commercial use ended in January 2019. Continuing to run Oracle JDK 8 in production without a subscription is a licensing question before it is a security one.
- Nothing stops if you are on a maintained OpenJDK 8 distribution. Temurin, Corretto, Zulu and Red Hat's build all continue to ship quarterly 8u security updates, and each publishes its own end date.
- What does erode is the ecosystem around Java 8: Spring Framework 6, Spring Boot 3, and most current library majors require Java 17 or later. Staying on 8 increasingly means staying on end-of-life frameworks too, which is the real exposure.
What actually breaks in the upgrade
The honest position: we do not patch the JVM
OSSeva does not fork or patch the Java runtime. That work is done well and for free by Temurin, Corretto and Zulu, and duplicating it would be a worse service than pointing you at them. What we patch is the layer above — Spring Framework, Spring Boot, Spring Security, Tomcat, Kafka clients — where the maintained-distribution story runs out. If a vendor tells you they provide 'Java 8 support' and cannot say precisely whether they mean the JVM or the frameworks running on it, that is the question to ask.
Switching JDK distribution is usually a one-line change and is free
Moving from Oracle JDK 8 to Eclipse Temurin 8 or Amazon Corretto 8 is, for the overwhelming majority of applications, a drop-in swap of the runtime with no code change. It removes the Oracle licensing exposure and restores a supported security update stream at zero cost. Teams paying for Java 8 'extended support' who have never evaluated this should do so first.
8 to 17 breaks on removed internals, not on language features
The blockers are the module system's encapsulation of sun.misc.Unsafe and other internals, the removal of the JAXB, JAX-WS and CORBA modules from the JDK, changed default garbage collector and TLS behaviour, and reflection-heavy libraries built before Java 9. The language changes are backwards compatible; the runtime changes are not.
The framework dependency is usually the real constraint
Most estates are not on Java 8 because of Java. They are on Java 8 because an application server, a vendor product, or a Spring Framework 5 codebase requires it. Sequence the work accordingly: the framework migration is the project, the JDK bump is a step inside it.
Your options, costed honestly
Including the ones that do not involve buying anything from us.
| Option | What it is | Effort | Cost | Our view |
|---|---|---|---|---|
| Move to a maintained OpenJDK 8 build | Swap Oracle JDK 8 for Eclipse Temurin, Amazon Corretto or Azul Zulu and keep receiving quarterly security updates. | Hours to days | Free | Do this first, before evaluating anything paid. It solves the security update question and the Oracle licensing question at once. |
| Upgrade to Java 17 or 21 | The real fix. Removed JDK modules and encapsulated internals are the work. | Weeks to months, driven by the frameworks not the JDK | Engineering time | The right destination. Usually blocked by a framework or vendor product, which is what to plan around. |
| Extended support for the frameworks on Java 8 | Keep Java 8 on a maintained build and take CVE patches for the Spring, Tomcat and middleware layers that are themselves end of life. | Days to onboard | Subscription | This is the gap OSSeva actually fills. The JVM is handled; the stack on top of it is not. |
| Oracle Java SE subscription | Pay Oracle for Java 8 updates and support. | Procurement | Per-employee pricing under the current model | Worth comparing against a free Temurin or Corretto swap before signing. For many estates the subscription buys support, not patches you cannot otherwise get. |
What OSSeva does for Java 8
Not covered — and here is why
We do not patch the JVM, and we will not quote you for it. Eclipse Temurin, Amazon Corretto, Azul Zulu and Red Hat maintain OpenJDK 8 properly and without charge, and the right advice is to use one of them. What we do cover is the end-of-life stack running on Java 8: Spring Framework 5.3, Spring Boot 2.7, Spring Security 5, Tomcat 8.5, and the messaging and data clients alongside them. If your Java 8 problem is really a Spring 5 problem, that is the conversation to have.
Spring Framework extended supportWhat your auditor will say
Running Oracle JDK 8 without a subscription is both an unpatched-component finding and a licensing exposure. Running a maintained Temurin or Corretto 8 build satisfies requirement 6.3.3 for the runtime — the finding then moves up the stack to the frameworks.
Auditors ask which distribution, not which version. 'Java 8' is not an answer; 'Temurin 8u, updated quarterly' is. Record the distribution in your asset inventory.
Java 8: common questions
Is Java 8 end of life?
It depends on the distribution. Oracle ended free public updates for commercial use in January 2019, but OpenJDK 8 is still actively maintained by Eclipse Temurin, Amazon Corretto, Azul Zulu and Red Hat, all of which ship quarterly security updates. Java 8 on a maintained OpenJDK build is supported; Oracle JDK 8 without a subscription is not.
Is it safe to still use Java 8 in 2026?
The runtime itself can be kept patched for free on a maintained OpenJDK distribution. The risk is usually one layer up: estates on Java 8 are typically also on Spring Framework 5 or Spring Boot 2, which are genuinely end of life and do not receive community patches.
Do I need to pay Oracle for Java 8 updates?
Usually not. Switching to Eclipse Temurin, Amazon Corretto or Azul Zulu is generally a drop-in runtime swap at no cost and restores a supported security update stream. Evaluate that before buying any Java 8 support subscription.
Does OSSeva patch Java 8?
No. We do not fork or patch the JVM, because Temurin, Corretto and Zulu already do it well and for free. We patch the end-of-life stack that runs on Java 8: Spring Framework 5.3, Spring Boot 2.7, Spring Security 5, Tomcat 8.5 and the middleware clients alongside them.
What breaks when upgrading from Java 8 to Java 17?
Not the language. The breakage is in removed JDK modules (JAXB, JAX-WS, CORBA), the encapsulation of internals like sun.misc.Unsafe, changed default garbage collection and TLS behaviour, and reflection-heavy libraries written before Java 9.
Why are so many enterprises still on Java 8?
Almost never because of Java itself. It is a framework, an application server, or a third-party product that requires it. The JDK bump is a step inside a framework migration, not a project on its own, which is why it keeps being deferred.
Still running Java 8?
Tell us the versions and the estate size. We will tell you honestly whether to upgrade or to buy cover — and we say 'upgrade' more often than you would expect.