Oracle JDK 17 LTS EOL Sept 2026: Week-by-Week Plan

The Countdown to Oracle JDK 17 LTS EOL: What Changes on September 30, 2026

With Oracle JDK 17 (LTS) reaching end of life on September 30, 2026, organizations still running this version face a hard deadline. After that date:

• No more public security patches – Oracle will not release updates for CVEs or other vulnerabilities.
• No bug fixes – Even critical stability issues will not be addressed.
• No vendor support SLA – Oracle’s support team will no longer assist with JDK 17 incidents.

For a long-term support release, this is the final curtain. The latest build in the 17 line is 17.0.20, and no further updates will follow.

Why Full Migration May Not Be Realistic in Three Months

Migrating a production Java estate—especially one relying on libraries, frameworks, or custom JNI code that may not be compatible with JDK 21 (the next LTS) or a non-Oracle distribution—takes time. Testing, certification, and rollback planning can stretch over months. For most organizations, a complete cutover before September 30, 2026 is no longer feasible.

That doesn’t mean you have to accept risk. Instead, shift focus to a pragmatic three-month plan that buys time while keeping operations safe.

A Week-by-Week Action Checklist (July – September 2026)

Use this timeline to prioritize. Adjust start dates based on when you read this, but keep the sequence.

Weeks 1-2: Inventory and Triage

• Identify every server, container, and application that uses Oracle JDK 17.
• Record version (java -version), JVM arguments, and dependencies.
• Classify systems by criticality: tier 1 (customer-facing, PCI), tier 2 (internal business), tier 3 (dev/test/legacy).
• Locate any reliance on Oracle-specific features (e.g., Flight Recorder, Mission Control, commercial license flags).

Weeks 3-4: Isolate and Harden

• Place tier-1 and tier-2 systems behind additional network layers (WAF, API gateway) where possible.
• Disable unnecessary JVM features (JMX exposed, debug ports) to reduce attack surface.
• If your environment supports it, containerize and run the JDK with a read-only filesystem.
• Review and tighten Java security policy files (java.security, policy files).

Weeks 5-6: Document Exposure for Auditors and Insurers

• Create a risk register entry for “Oracle JDK 17 LTS post-EOL operation.”
• Document the mitigation steps taken (isolation, hardening, monitoring).
• Calculate the maximum impact if a CVE is exploited in each tier.
• Share the register with compliance, audit, and cyber insurance contacts. Many insurers now require explicit disclosure of EOL software in use.

Weeks 7-8: Establish a Migration Path (Even If Slow)

• Identify the target JDK (e.g., Oracle JDK 21 LTS, or a non-Oracle distribution like OpenJDK builds from providers that offer extended support).
• Set up a test environment mirroring production and begin compatibility testing for the highest-priority applications.
• Plan a phased roll-out: start with non-critical workloads, then tier-3, then tier-2, deferring tier-1 until fully proven.

Weeks 9-10: Line Up Day-One Support

• Evaluate third-party support options for Oracle JDK 17. Third-party support can provide security patches and expert triage after Oracle stops, often at lower cost than a forced migration.
• Negotiate and sign a support contract so it’s active on October 1, 2026. Do not wait—vendors need time to onboard your environment.
• Ensure your new support provider can handle JDK-specific issues, not just OS or hardware.

Weeks 11-12: Final Checks and Communication

• Confirm support contract is in place and contact information distributed to ops teams.
• Run a staged dry-run of an incident response drill for a post-EOL CVE (e.g., simulate a critical patch that would normally come from Oracle).
• Notify internal stakeholders (security, IT, business owners) that the EOL date has passed and that the risk register is active.

What Happens on October 1, 2026?

Nothing breaks immediately. Your applications will still run. But:

• If a new zero-day vulnerability is disclosed, there will be no patch from Oracle.
• If you encounter a runtime bug affecting performance or reliability, Oracle will not provide a fix.
• Your audit logs will show an unsupported JDK, potentially flagging compliance violations (e.g., PCI DSS, SOC 2).

The risk is accumulative – each day without support increases exposure. That’s why a support contract covering the EOL period is essential.

Keep Oracle JDK 17 Running Safely After EOL

Third-party support for Oracle JDK 17 can fill the gap. A provider like Third Party Support delivers:

• Backported security patches for confirmed CVEs.
• Technical support for JDK 17-specific issues.
• Proactive monitoring and compatibility guidance for your planned migration.

This gives you the time and safety to migrate at your own pace, without forcing a rushed, expensive rip-and-replace.

[Contact us] to discuss a support plan for your Oracle JDK 17 estate. We’ll help you get coverage in place before September 30.

---

Lifecycle data sourced from endoflife.date/oracle-jdk. Latest Oracle JDK 17 release: 17.0.20. Learn more about Oracle software lifecycle on our Oracle support page.