Oracle Java Licensing for Legacy Versions (6, 7, 8, 11): What Requires a License & Support Options
Legacy Java is pervasive in enterprise systems — embedded in ERP platforms, middleware, and internal applications that never got updated.
However, the licensing rules for each Java version vary drastically, and misunderstanding these differences has become a common cause of compliance issues and Oracle audit findings.
This article explains how Oracle licenses older Java versions (6, 7, 8, and 11) as of 2026, which of them require a paid license or subscription, and what support options exist to stay secure and compliant without unnecessary Oracle spend.
Pro Tip: “The older the Java, the newer the compliance risk.”
The Legacy Java Timeline
Before diving into each version, it’s useful to understand its release timeline and support schedule.
The table below shows each Java version’s initial release date, when Oracle stopped providing free public updates, when Oracle’s extended support ended (or will end), and whether a license is required to use it today:
| Version | Initial Release | Free Public Updates Ended | Extended Support End | License Required Today? |
|---|---|---|---|---|
| Java 6 | 2006 | Apr 2013 | Dec 2018 (support ended) | ✅ Yes (commercial use) |
| Java 7 | 2011 | Apr 2015 | Jul 2022 (support ended) | ✅ Yes (commercial use) |
| Java 8 | 2014 | Jan 2019 (commercial) | Dec 2030 (extended) | ✅ Yes (commercial use) |
| Java 11 | 2018 | Sep 2023 (public) | Sep 2032 (extended) | ⚠️ Depends on source |
Pro Tip: “Every version before Java 17 has a licensing catch — Oracle made sure of it.”
Understanding Licensing Status by Version
Each legacy Java version has its own licensing status and requirements. Below is a breakdown of what it means to run Java 6, 7, 8, or 11 today in terms of licensing and support:
Java 6 & Java 7 – Fully Commercial
Java 6 and Java 7 are both well beyond their end-of-life dates. Oracle stopped providing public (free) updates for Java 6 in April 2013 and for Java 7 in April 2015. Since then, any continued use of Oracle’s Java 6 or 7 in a commercial environment technically requires a paid license or support contract. In practice, Oracle now only makes Java 6 and 7 available to customers with an active Java SE support subscription.
- Support options: Organizations still running Java 6/7 must either maintain an Oracle Java SE Subscription (which provides legal access and support for legacy versions) or seek third-party long-term support from vendors like Azul, BellSoft, or Red Hat that offer extended support for outdated Java.
- Strategy: Plan to migrate applications off Java 6 and 7 as soon as possible. If these older systems cannot be retired immediately, isolate them (e.g., run them on segregated VMs or networks) to contain compliance and security exposure.
Java 8 – The Most Widely Used Legacy Version
Java 8, released in 2014, remains enormously popular due to its stability and the vast number of applications built on it. Oracle ended free public updates for commercial users of Java 8 as of January 2019.
After that date, any Oracle JDK 8 updates have been available only to paying customers. In other words, running Oracle JDK 8 in production today requires a Java SE Subscription (or another paid Oracle support plan). This has a significant impact given how many enterprises still rely on Java 8.
Options for Java 8 users: You have a few routes to stay compliant and secure on Java 8, outlined below:
| Option | Description | Cost | Notes |
|---|---|---|---|
| Oracle Java SE Subscription | Official Oracle support & updates for Java 8 | $$$ | Full support and compliance coverage from Oracle |
| OpenJDK 8 (community build) | Free open-source builds (e.g. Adoptium, Red Hat) | $ | No cost to use; no Oracle support (self-support) |
| Azul Zulu Enterprise | Third-party commercial support for Java 8 | $$ | Long-term security patches available through 2030 |
Pro Tip: “If you’re still on Java 8, you’re paying — either in money or in risk.”
Java 11 – The First “Modern” LTS Under Mixed Terms
Java 11, released in 2018, marked a turning point in Oracle’s licensing model. Oracle’s JDK 11 is provided under an Oracle Technology Network (OTN) license that permits free use only for development, testing, or personal purposes. Any commercial production use of Oracle JDK 11 requires a paid Java SE Subscription.
This “free for dev, pay for prod” model was new, and many organizations initially misunderstood it. In effect, if you’re running Oracle’s Java 11 in production without a subscription, you are not compliant with Oracle’s license terms.
The good news is that Java 11 is also available as OpenJDK, which is completely free and open-source (GPL license). Multiple vendors (Adoptium, Amazon Corretto, Azul, and others) provide builds of OpenJDK 11 that can be used freely in production and receive ongoing updates.
These OpenJDK builds are functionally equivalent to Oracle JDK, minus a few proprietary tools, and receive regular security patches from the community or vendor maintainers.
- Strategy: Companies still on Java 11 can avoid Oracle fees by switching to an OpenJDK 11 distribution for production. If your applications are certified only on Oracle JDK 11, consider migrating them to Java 17 as a next step. Oracle offered Java 17 under a No-Fee Terms and Conditions (NFTC) license during its initial support period – meaning Java 17 was free for commercial use until that period ended in late 2024. Leveraging Java 17’s no-fee window can buy you time to upgrade off Java 11 without immediate costs. (After the free period, you would either move to the next LTS or start incurring subscription requirements, so plan accordingly.) Another option is to move directly to OpenJDK 17+ or other vendor-supported JDKs to remain free of Oracle’s licensing altogether.
Pro Tip: “Java 11 is where Oracle’s ‘free but not really free’ era began.”
Licensing by Source – Oracle vs OpenJDK Builds
For any Java version, the licensing obligations depend on whether you use Oracle’s official binary or an OpenJDK-based build from the community or third parties.
Oracle’s distributions typically carry restrictions or fees for commercial use, whereas OpenJDK distributions are generally free (with support optionally available from other vendors). The table below summarizes the differences and recommendations for each legacy version:
| Java Version | Oracle JDK (Oracle’s License Terms) | OpenJDK (Open-Source License) | Recommendation |
|---|---|---|---|
| Java 6 | Commercial use only (Oracle BCL; updates ended) | Community builds unsupported (no updates) | Retire or isolate if possible |
| Java 7 | Commercial use only (Oracle BCL; updates ended) | Community builds unsupported (no updates) | Retire or isolate if possible |
| Java 8 | Paid license required (Oracle SE Subscription) | Free under GPL (OpenJDK from other vendors) | Use vendor-supported OpenJDK builds |
| Java 11 | OTN license (free for dev/test; subscription for prod) | Free under GPL (available from multiple sources) | Use OpenJDK builds for production |
(BCL = Oracle’s old Binary Code License for Java; OTN = Oracle Technology Network license)
In general, choosing an OpenJDK build for legacy Java lets you continue using that version with a source of updates (community or vendor-provided) without falling under Oracle’s commercial license requirements. The trade-off is that you won’t get support from Oracle — but as we’ll see, third-party support can fill that gap.
Extended Support – How It Works
Oracle’s support for Java versions doesn’t vanish immediately when public updates end. For long-term support (LTS) releases like 8 and 11, Oracle offers Extended Support, which is a paid continuation of updates beyond the public update period.
However, this extended support is time-limited and comes at an additional cost (often built into the Java SE Subscription for current customers).
For Java 6 and 7, the extended support window has already expired – Oracle will no longer provide any patches for those versions, even to paying customers. Java 8 and 11, on the other hand, are still within Oracle’s extended support period as of 2026.
That means Oracle continues to release critical fixes for Java 8 and 11, but only for organizations with an active subscription (Java SE Universal Subscription). The table below outlines the extended support timelines:
| Java Version | Extended Support Until | Covered by Oracle Subscription? |
|---|---|---|
| Java 6 | Dec 2018 (support ended) | No – beyond support window |
| Java 7 | Jul 2022 (support ended) | No – beyond support window |
| Java 8 | Dec 2030 | Yes – included with subscription |
| Java 11 | Sep 2032 | Yes – included with subscription |
Oracle has effectively bundled extended support for Java 8 and 11 into its current subscription model (no extra “extended support” fees for those versions) because so many customers still need them.
Keep in mind, though, these end dates are hard stops — once Java 8 hits the end of 2030, Oracle will stop issuing fixes, and companies will be expected to move to a newer Java platform. Extended support can buy you time, but it’s not a permanent safety net.
Third-Party Support Options
The good news for enterprises running legacy Java is that you’re not forced to rely on Oracle for updates.
Several third-party vendors provide their own long-term support for Java, via builds of OpenJDK, often at significantly lower cost than Oracle’s subscription (and sometimes at no cost for certain usage). This can be a game-changer for avoiding Oracle’s “Java tax.”
Notable third-party support options include Azul Systems, Red Hat, and BellSoft, among others:
| Vendor | Legacy Versions Covered | Approx. Cost (Relative) | Support Duration (LTS) |
|---|---|---|---|
| Azul (Platform Core/Prime) | Java 6–17 | ~30–50% of Oracle’s price | 8+ years of patch support |
| Red Hat (OpenJDK) | Java 8, 11, 17 | Free with RHEL subscription | 5+ years per major release |
| BellSoft (Liberica) | Java 8–17 | Low-cost support plans | ~10 years (extended LTS) |
Each of these vendors offers regular security updates for older Java versions, independent of Oracle. For example, Azul continues to provide Java 6 and 7 updates to its customers long after Oracle dropped support. Red Hat backports fixes to OpenJDK 8 and 11 and provides those updates to Red Hat Enterprise Linux users at no extra charge. BellSoft similarly offers ongoing updates for its Liberica JDK builds.
Strategy: Using a vendor-supported OpenJDK distribution can eliminate Oracle licensing obligations while maintaining your Java environments’ security.
Many organizations choose to replace Oracle’s JDK/JRE with one of these supported builds on their servers. This way, you continue to get critical patches for Java 6, 7, 8, or 11, but you pay far less (or nothing) to a provider other than Oracle for that peace of mind.
Compliance & Audit Triggers for Legacy Java
From a compliance perspective, legacy Java installations pose an audit risk.
Oracle auditors often zero in on older Java versions during license reviews because:
- Easy to detect: Outdated Java versions frequently attempt to check for updates or have identifiable version signatures. Oracle can detect these through update telemetry or network scans, making legacy installs low-hanging fruit to discover.
- Overlooked by IT: Many companies lose track of where Java is installed. Java might be embedded in older enterprise apps or appliances. These instances can fly under the radar if no one manages their licensing.
- Lack of entitlement: If you’re running an older Oracle JRE/JDK downloaded years ago, you may not have a current support contract for it. Oracle knows that Java 6, 7, 8, and 11 deployments often lack proper licensing documentation, making them ripe for audit findings.
All of this means that if you are using Oracle’s Java in production and it’s an older version, you should assume Oracle will be interested. Non-compliance penalties or forced subscription deals can be expensive.
To mitigate these risks, be proactive in managing legacy Java use. Perform a thorough inventory of all Java installations (especially versions 6–11). Replace Oracle-supplied runtimes with OpenJDK-based alternatives wherever possible.
And if you do need to keep an Oracle Java runtime in use, ensure you have the appropriate subscription or support agreement, and keep the proof on file. In short: know where your Java is, and document that you’re licensed or supported.
Checklist – Staying Compliant on Legacy Java
Use the following checklist to stay on top of Java licensing compliance and security:
- ✅ Identify every Java installation in your environment (especially versions 6–11 still running).
- ✅ Verify the source of each Java – determine if it’s Oracle’s JDK/JRE or an OpenJDK distribution.
- ✅ Replace unsupported Oracle builds with vendor-supported OpenJDK builds for older versions (swap out that Oracle JRE 8 for an OpenJDK 8 from a trusted provider).
- ✅ Secure a patch update plan for any legacy Java you must keep (either via an Oracle Java SE Subscription or a third-party support contract, to ensure you get security updates).
- ✅ Maintain license records – archive proof of any Oracle Java licenses or support agreements you hold, to defend against audits.
Strategic Recommendations for 2026
Finally, here are five strategic steps for enterprises to manage legacy Java versions in the future:
1️⃣ Phase Out Java 6 and 7 — These oldest versions are end-of-life; plan to retire or isolate any systems still using Java 6 or 7 as a top priority.
2️⃣ Migrate Java 8 to Java 17 (NFTC) — Take advantage of Java 17’s no-fee terms (during its initial release window) to upgrade applications from Java 8 without immediate licensing costs. This gives you a free-supported LTS to bridge the gap.
3️⃣ Standardize on OpenJDK — Make OpenJDK distributions (from vendors like Adoptium, Azul, Amazon, etc.) the default for your Java deployments. This reduces dependency on Oracle and avoids recurring license fees.
4️⃣ Negotiate Before Oracle Knocks — If you do require Oracle’s Java (and can’t fully migrate), engage Oracle for a subscription proactively rather than waiting for an audit. You’re likely to get better terms by addressing it upfront than under audit pressure.
5️⃣ Plan Regular LTS Upgrades — Every new Java LTS release resets your support clock. Establish an upgrade cycle (e.g., move to Java 17, then 21, then 25, etc., on a schedule) so you’re always within a supported version. This way, you won’t find yourself stuck on an outdated Java that forces you into costly extended support.
Pro Tip: “The cheapest way to manage old Java is to stop running it.”
By following these practices, enterprises can navigate Oracle’s licensing rules for legacy Java versions, stay compliant, and control costs — all while keeping critical systems secure.
