EOSL Alerts

Oracle JDK 22 End of Life: Sept 17, 2024 Action Plan

Updated 3rd Party Support Team

Oracle JDK 22 End of Life: A Last-Call Action Plan

Oracle JDK 22 reaches end of life (EOL) on September 17, 2024. Because this is a non-LTS release, no further updates will be issued after that date. The final release in this line is version 22.0.2. With about three months until the deadline, migrating every workload to a supported LTS version is no longer realistic for most estates. Instead, a pragmatic last-call plan is needed to manage risk until a full migration can be completed.

What Changes on September 17, 2024

After the EOL date:

  • Oracle will release no more security patches, bug fixes, or performance updates for JDK 22.
  • Official vendor support ceases — no SLAs, no hotfixes, no incident response.
  • Any vulnerability discovered in JDK 22 after this date will remain unpatched unless you have an alternative support arrangement.

Your systems will continue to run, but they become exposed. Regulators, auditors, and cyber-insurers increasingly view unsupported software as an unacceptable risk.

Your Three-Month Action Plan

The following week-by-week checklist assumes you are starting now (mid-June 2024). Adjust if your start date is different, but the sequence remains the same.

Weeks 1–2: Inventory Every JDK 22 Instance

  • Scan all servers, containers, developer workstations, and CI/CD pipelines for JDK 22 installations.
  • Record each instance’s version (including 22.0.x), purpose, owner, and network exposure.
  • Use commercial or open-source asset-discovery tools if available.

Weeks 3–4: Categorize and Isolate

  • Separate JDK 22 usage into three buckets:
    • Critical: Internet-facing, handling sensitive data, or required for revenue.
    • Important: Internal line-of-business apps with limited exposure.
    • Non-critical: Dev/test, deprecated apps, or easily replaced tasks.
  • Immediately shut down or containerize non-critical instances where feasible.
  • For important and critical instances, begin network isolation: restrict inbound/outbound traffic, place behind firewalls, and enforce least privilege.

Weeks 5–6: Harden Remaining Systems

  • Apply all available patches up to 22.0.2 — ensure no JDK 22 instance is running an earlier version.
  • Review Java security settings: disable weak ciphers, limit permissions, enable security manager if applicable (though deprecated, it still provides some boundaries).
  • Use application-level protections such as Web Application Firewalls (WAF), runtime application self-protection (RASP), or intrusion detection.
  • Enable comprehensive logging and monitoring for all JDK 22 processes.

Weeks 7–8: Document Exposure for Auditors and Insurers

  • Create a risk register listing every JDK 22 instance, its business impact, and mitigation measures taken.
  • Estimate the cost of a potential security incident and document your plan to transition away from JDK 22.
  • Share this documentation with internal audit, compliance, and cyber-insurance contacts. Many policies now explicitly require an inventory of unsupported software.

Weeks 9–10: Secure a Support Contract

  • Research third-party maintenance providers that specialize in Java runtimes. Third-party support can deliver:
    • Critical security patches after Oracle EOL
    • Technical support and SLAs
    • Compatibility fixes for your specific environment
  • Evaluate providers based on patch coverage, response times, and references.
  • Sign a contract to start coverage on September 17, 2024 — the day Oracle support ends.

Weeks 11–12: Final Testing and Go-Live

  • Test the selected third-party support process: confirm you can receive patches and open tickets.
  • Verify that all hardening and isolation measures are working.
  • Conduct a tabletop incident exercise for a Java zero-day scenario post-EOL.
  • Communicate the status to stakeholders: what is still running JDK 22, why, and how risk is managed.

Why Third-Party Support Is Your Best Option Now

Given the timeline, a complete migration before September 17 is unlikely. Third-party support bridges the gap safely. Providers can often patch vulnerabilities in older JDK releases without requiring a version upgrade, preserving application stability while maintaining security. This gives you time to plan a careful, phased migration to an LTS release (such as JDK 21 or the upcoming JDK 23 LTS) without rushing.

Act This Week

Don’t wait until September to discover you have dozens of unsupported JDK 22 instances. Start your inventory today, isolate what you cannot yet migrate, and secure a support contract for the day Oracle stops. By following the checklist above, you can keep your operations safe, satisfy auditors, and buy the time needed for a controlled transition.

For more information on third-party maintenance for Oracle JDK, see our Oracle software support page. If you need help selecting a support provider or want to discuss your specific estate, contact us.

How we can help

Keep it supported after end of life

The vendor's date doesn't have to be yours. Our engineers keep Oracle JDK 22 running after official support ends — independent third-party support that covers most operational issues, typically at 40-70% below the last renewal quote.

Oracle OS software support →

Migration services

When you do decide to move, we plan and execute the migration. Your current environment stays under vendor support while your contract is active — and if the renewal lapses mid-move, our third-party support covers most issues until the last workload is off it.

Migration & hybrid cloud services →

24×7 remote administration

Short on hands to run it day to day? Our NOC engineers monitor, patch and administer your environment around the clock — incident response included, at a fraction of the cost of an in-house night shift.

24/7 operations & remote administration →

Talk to a support specialist

Speak with an engineer, not a sales rep. We respond within 24 hours.

Your quote will be sent to this address.

By submitting this form, you agree to our Privacy Policy.