Java 8 is not simply "end of life" or "supported". Oracle's support roadmap lists Premier Support for Java SE 8 as ended in March 2022 and Extended Support running until December 2030. Whether your copy still gets fixes depends on which vendor built it and what support you hold.
What Oracle's roadmap says
Oracle publishes a Java SE support roadmap. For Java SE 8 it lists a general availability date of March 2014, Premier Support until March 2022, Extended Support until December 2030, and Sustaining Support as indefinite. The same page marks Java SE 8, 11, 17, 21 and 25 as long-term support (LTS) releases.
Those dates describe Oracle's own product support. They are not a statement about every Java 8 runtime in your estate. Other vendors ship Java 8 builds under their own schedules, and those dates have to be read from each vendor's page. Treat any date you cannot find on a vendor page as unknown rather than guessing.
Premier, Extended and Sustaining in plain words
| Phase | What it generally means | Inventory status to record |
|---|---|---|
| Premier Support | Full support with update releases | Supported |
| Extended Support | Continued support, usually requiring a support contract | Extended |
| Sustaining Support | Existing releases and documentation, no new fixes promised | Treat as unsupported for patching |
The word "usually" matters. Check the terms that apply to you. If your team is not paying for support, an Extended Support date on a roadmap does not mean you are receiving updates.
Why Java 8 hides in inventories
Java 8 shows up in places teams forget: a build server image, an application server bundled with its own JRE, a vendor appliance, a Dockerfile that pins an old base image tag. A dependency scanner that only reads your manifest will list libraries and miss the runtime entirely. If you suspect that gap, read does a dependency scanner check Node, Python or the JDK.
To find real usage, look in three places:
- Container and VM images, for the Java version string.
- Build files, for source and target compatibility settings, which show what your code is compiled for.
- Startup scripts and service definitions, which often point at a specific JAVA_HOME path.
A library compiled for Java 8 can usually run on a newer JVM, so the runtime and the bytecode level are separate records. Write both down.
What to record for each Java 8 finding
- Runtime vendor and exact version, not just "Java 8".
- Where it runs: service, image, host.
- Support status and the date you verified it, with the page you used.
- Owner and the upgrade plan, even if the plan is "extend until a stated date".
- Exposure: internet-facing or internal, and whether it handles untrusted input.
An EOL or aging runtime is a risk multiplier, not a single finding. A runtime with a known fix available is more urgent than one that is merely old. See which end-of-life component to fix first for an ordering method, and upgrade, extend, isolate or retire for the decision itself.
Try it yourself
Click through it at your own pace, or open it full screen. Look at how components are listed with versions, then picture adding a support date column next to each one.
Where Safeguard fits
Safeguard's SBOM and dependency scanning builds the component list, and asset discovery helps find services you did not know were running. You decide the lifecycle fields you attach. You can try a free scan at gold.safeguard.sh/scan.
Quick check
Is Java 8 still safe to run?
It can be, if you hold a support arrangement that delivers updates and you apply them. Without updates, treat it as a growing risk and plan an upgrade or an isolation step.
Does a roadmap date mean I get patches?
No. It states what the vendor offers under its terms. Your entitlement depends on your contract and the build you run.
Do I need to record the bytecode level separately?
Yes. The runtime version and the compile target are different facts, and upgrades often change one before the other.
Sources
Last reviewed: 19 October 2026.
