The Legacy Java Timeline — Release, Support, and Licensing Status

VersionInitial ReleaseFree Public Updates EndedOracle Extended Support EndLicence Required Today?
Java 62006April 2013December 2018 (ended)✅ Yes — commercial use requires subscription
Java 72011April 2015July 2022 (ended)✅ Yes — commercial use requires subscription
Java 82014January 2019 (commercial)December 2030✅ Yes — commercial use of Oracle JDK requires subscription
Java 112018September 2023 (public)September 2032⚠️ Depends — Oracle JDK requires subscription for production; OpenJDK is free
Java 172021NFTC free period ended late 2024September 2029⚠️ NFTC period ended — now requires subscription for Oracle JDK updates

Licensing Status by Version — Detailed Analysis

Java 6 & Java 7 — Fully Commercial

End-of-Life — Highest Risk

Java 6 and 7 are well beyond end-of-life. Oracle stopped free public updates for Java 6 in April 2013 and Java 7 in April 2015. Extended support has also expired (Java 6: December 2018, Java 7: July 2022). Any continued use of Oracle's Java 6 or 7 in a commercial environment requires a paid Java SE Subscription. Oracle now only makes Java 6/7 available to customers with active subscriptions. No patches are available from Oracle even for paying customers (beyond the support window). Strategy: migrate applications off Java 6/7 as a top priority. If systems cannot be retired immediately, (a) isolate them on segregated VMs/networks to contain compliance and security exposure, and (b) evaluate third-party support from Azul or BellSoft, which still provides patches for these versions.

Java 8 — Most Widely Used Legacy Version

Licence Required — Multiple Options Available

Java 8 remains enormously popular due to its stability and the vast number of applications built on it. Oracle ended free commercial updates in January 2019 — running Oracle JDK 8 in production today requires a Java SE Subscription. Under the January 2023 employee-based model, this costs $8.33/employee/month (not per Java user — per total employee headcount). For a 10,000-employee organisation, that is $1M/year. However, Java 8 is also available as OpenJDK from multiple free sources (Eclipse Temurin, Amazon Corretto, Azul Zulu, Red Hat OpenJDK). These builds are functionally equivalent and receive ongoing security patches. Strategy: migrate from Oracle JDK 8 to an OpenJDK 8 distribution for immediate compliance and cost elimination, or upgrade to Java 17/21.

Java 11 — "Free for Dev, Pay for Prod"

Oracle JDK Requires Subscription — OpenJDK Is Free

Java 11 introduced Oracle's split licensing model: Oracle JDK 11 is free for development and testing (OTN licence) but requires a paid Java SE Subscription for any commercial production use. Many organisations initially misunderstood this — running Oracle JDK 11 in production without a subscription is non-compliant. The good news: Java 11 is also available as OpenJDK under GPL licence — completely free for production. Multiple vendors (Adoptium, Amazon Corretto, Azul, Red Hat) provide OpenJDK 11 builds with ongoing security patches. Strategy: replace Oracle JDK 11 with OpenJDK 11 for production. If upgrading, consider moving directly to Java 17 or 21 on OpenJDK distributions to reset onto a modern LTS with longer community support windows.

Oracle JDK vs OpenJDK — Licensing by Source

VersionOracle JDK (Oracle's Terms)OpenJDK (Open Source)Recommendation
Java 6Commercial only (BCL); updates ended entirelyCommunity builds unsupported; no updates availableRetire or isolate; third-party support (Azul) for patches
Java 7Commercial only (BCL); updates ended entirelyCommunity builds unsupported; no updates availableRetire or isolate; third-party support (Azul) for patches
Java 8Subscription required ($8.33/employee/month)Free under GPL — Temurin, Corretto, Zulu, Red HatUse vendor-supported OpenJDK builds — eliminate Oracle obligation
Java 11OTN: free dev/test only; production requires subscriptionFree under GPL — multiple vendor builds availableUse OpenJDK for production — zero Oracle licence cost
Java 17NFTC free period ended late 2024; subscription now required for updatesFree under GPL — community and vendor buildsUse OpenJDK; plan LTS upgrade cycle (17 → 21 → 25)

Extended Support Timelines

Java 6 & 7 — Support Expired

Oracle extended support for Java 6 ended December 2018; Java 7 ended July 2022. Oracle will no longer provide patches for these versions even to paying customers. Organisations still running Java 6/7 on Oracle JDK have no path to Oracle-provided security updates. The only options for continued patching are third-party providers (Azul supports Java 6+ through its Platform Core offering). For compliance purposes, Oracle considers any commercial use of Java 6/7 without an active subscription as unlicensed — but even with a subscription, no new patches are available. This creates a security-without-compliance paradox that can only be resolved by migration or third-party support.

🔄

Java 8 & 11 — Still in Extended Support

Oracle continues to release critical patches for Java 8 (through December 2030) and Java 11 (through September 2032) — but only for customers with active Java SE Subscriptions. Extended support is effectively bundled into the current subscription model (no separate extended support surcharge). These end dates are hard stops: once Java 8 reaches December 2030, Oracle will cease all patches, and organisations must have migrated to a newer LTS. For Java 11, the September 2032 window provides more runway. CIO action: use the extended support windows as migration deadlines — plan Java 8 → 17/21 migration to complete before 2030, and Java 11 → 21/25 migration before 2032.

Third-Party Support Options

VendorLegacy Versions CoveredApproximate CostSupport DurationKey Benefits
Azul (Zulu / Platform Core)Java 6, 7, 8, 11, 17~30–50 % of Oracle's price8+ years per LTS releaseBroadest legacy coverage including Java 6/7; commercially supported patches
Red Hat (OpenJDK)Java 8, 11, 17Free with RHEL subscription5+ years per major releaseZero incremental cost for RHEL customers; integrated with Red Hat ecosystem
Amazon CorrettoJava 8, 11, 17, 21Free — no subscription requiredMinimum 4 years per LTSZero cost; production-ready; backed by Amazon engineering
BellSoft (Liberica)Java 8, 11, 17, 21Low-cost commercial plans~10 years (extended LTS)Extended LTS support; multiple packaging options (JRE, JDK, full, lite)
Eclipse Temurin (Adoptium)Java 8, 11, 17, 21Free — community-maintainedPer OpenJDK community scheduleVendor-neutral; community-governed; widely adopted as Oracle JDK replacement

Compliance and Audit Triggers for Legacy Java

Legacy Java installations represent the highest-risk audit area in most Oracle estates. Oracle auditors specifically target older Java versions because they are easy to detect, frequently overlooked by IT, and commonly lack proper licensing documentation.

🔍

Why Oracle Targets Legacy Java

Three factors make legacy Java the most productive audit target: (1) easy detection — Oracle JDK installations have identifiable version signatures, auto-update check-in telemetry, and registry/file-system fingerprints that Oracle's audit tools detect readily; legacy Java on workstations frequently phones home to Oracle's update servers, revealing the installation, (2) overlooked by IT — Java is often embedded in enterprise applications (ERP, middleware, proprietary tools) or bundled with third-party software, creating installations that IT teams don't manage or even know exist; these "shadow Java" deployments are the most common audit finding, and (3) lack of entitlement — organisations that downloaded Oracle JDK years ago during the free-for-commercial-use era (pre-2019 for Java 8, pre-2023 for Java 11) often have no current support contract or subscription covering continued use. Oracle knows this pattern and designs audit inquiries to surface exactly these gaps.

🛡️

Oracle's Audit Escalation Pattern for Java

Oracle typically follows a three-phase escalation for Java licensing: Phase 1 (Weeks 1–4): soft inquiry — a letter or email from Oracle's licence management team requesting information about Java deployments, framed as a "compliance check" or "licence review." Phase 2 (Weeks 4–12): subscription proposal — Oracle presents a Java SE Subscription proposal, often with a "limited-time discount" for proactive adoption, accompanied by an estimated deployment count (frequently inflated). Phase 3 (Months 3–9): escalation — if the organisation does not subscribe, Oracle may escalate to formal audit proceedings, engage legal resources, or reference contract audit rights. Critical insight: Oracle rarely proceeds to litigation for Java licensing — the escalation is designed to create pressure to subscribe. Organisations with a documented migration plan, accurate deployment inventory, and independent advisory consistently achieve better outcomes than those who respond reactively.

Compliance Checklist — Staying Compliant on Legacy Java

✅ Java Compliance Checklist

  • Identify every Java installation in your environment: Use automated scanning tools (SCCM, BigFix, Snow, Flexera, or custom scripts targeting java.exe/javaw.exe) to discover every Oracle JDK and JRE installation across workstations, servers, VMs, and containers — especially versions 6–11. Include third-party applications that bundle their own Java runtime
  • Verify the source of each Java installation: Determine whether each installation is Oracle JDK/JRE or an OpenJDK distribution (Temurin, Corretto, Zulu, etc.). Oracle JDK installations carry licensing obligations; OpenJDK installations under GPL do not. The java -version command output distinguishes between Oracle and OpenJDK builds
  • Replace Oracle JDK with vendor-supported OpenJDK: For Java 8, 11, and 17 — swap Oracle JDK with an OpenJDK distribution (Temurin, Corretto, Azul Zulu). This eliminates Oracle licensing obligations immediately. Validate application compatibility with OpenJDK before deployment (compatibility is typically 99%+ as they share the same codebase)
  • Secure a patch plan for every remaining Java installation: If any legacy Java must remain, ensure it receives security updates — either through Oracle Java SE Subscription or a third-party support contract (Azul, BellSoft). Running unpatched Java is both a security risk and a compliance liability
  • Maintain licence records and documentation: Archive proof of any Oracle Java licences, support agreements, and subscription confirmations. If you have migrated to OpenJDK, document the migration (dates, scope, verification) to defend against retroactive Oracle claims for periods when Oracle JDK was in use
  • Implement Java deployment governance: Prevent future Oracle JDK installations by controlling software deployment channels — block Oracle JDK downloads via proxy/firewall rules, use centralised software distribution for approved OpenJDK builds, and include Java licensing verification in new application deployment approvals
  • Plan LTS upgrade cycles: Establish a regular upgrade cadence (Java 8 → 17 → 21 → 25) aligned with OpenJDK community support timelines. Each LTS upgrade resets your support window and ensures you never fall behind into a version that requires paid extended support

Strategic Recommendations for 2026

1️⃣

Phase Out Java 6 and 7

These oldest versions are fully end-of-life with no patches available even from Oracle. Retire or isolate any systems still running Java 6 or 7 as the highest priority. If retirement requires application remediation, engage third-party support (Azul) as a bridge while migration is planned. Every month these versions remain in production increases both security vulnerability and Oracle audit exposure.

2️⃣

Migrate Java 8 to OpenJDK or Java 17/21

Java 8 is the single largest source of Oracle Java licensing exposure due to its ubiquity. Two migration paths: (a) replace Oracle JDK 8 with OpenJDK 8 (Temurin, Corretto, Zulu) for immediate compliance with minimal application change, or (b) upgrade to Java 17 or 21 on OpenJDK for long-term positioning. Path (a) is faster; path (b) is more future-proof. Most organisations execute path (a) first, then upgrade to modern LTS on a planned schedule.

3️⃣

Standardise on OpenJDK

Make OpenJDK distributions the default for all Java deployments — development, testing, and production. This eliminates Oracle licensing dependency entirely. Establish an approved list of OpenJDK distributions (Temurin, Corretto, Azul Zulu) and block Oracle JDK downloads via proxy/firewall rules. The transition is functionally transparent — OpenJDK and Oracle JDK share the same codebase and pass the same TCK compatibility tests.

4️⃣

Negotiate Proactively If Oracle Subscription Is Needed

If you genuinely require Oracle's Java SE Subscription (and cannot migrate), engage Oracle proactively rather than waiting for an audit. Proactive negotiation consistently achieves 40–60 % better pricing than audit-pressured subscription purchases. Key leverage: demonstrate a credible migration timeline to OpenJDK — Oracle will discount to retain revenue rather than lose the customer entirely. Independent advisory delivers 5–15× ROI on Java subscription negotiations.

"The older the Java, the newer the compliance risk. Oracle's employee-based pricing model means that legacy Java installations that cost nothing to deploy can now generate millions in licensing exposure based on your total headcount — not the number of people using Java. The cheapest and most effective strategy is to stop running Oracle JDK entirely." — Redress Compliance Advisory