Java support in 2026 comes down to three separate checks: which JDK build you run, who will ship its next security update, and who answers when production fails. For most business applications the safe choice is one of three paths: move to Java 25, keep Java 21 on a distribution with a clear update plan, or hold an older runtime for a short, documented period. A rewrite is rarely the first step.
Java decisions often stall because "Java is free" and "Java needs a paid license" get mixed up. Both can be true, depending on the vendor, the build and the agreement. This guide shows how we sort that out before anyone touches the code.
What are the three Java support questions?
For each production deployment, answer these three questions on their own:
- Can we use this exact build for this workload? Record the distribution, version, download source, license and any subscription.
- Who supplies the next security update? Check the vendor's roadmap for your operating system and chip architecture, not just the major version.
- Who responds when production breaks? Decide whether you rely on community help, a paid support contract or your own engineers.
The answers often differ. Eclipse Adoptium offers community support for Temurin and points companies that need service-level agreements to outside providers. Amazon's Corretto FAQ says Corretto updates are no-cost and separate from AWS Support plans. Neither one means "free Java includes enterprise incident support."
What changed with Oracle JDK 21 in 2026?
Oracle's Java SE Support Roadmap says Oracle JDK 21 releases as of October 20, 2026 are available under the Java SE OTN license. Oracle JDK 25 updates are planned to move to the OTN license after September 2028. These are rules for Oracle's own builds. They do not end free Java 21 updates from other vendors.
Oracle's licensing FAQ lists the no-cost uses the OTN license allows, such as development and testing. Do not assume those cover ordinary commercial production. Have procurement or legal confirm your agreement and any existing entitlement.
Oracle's paid support dates are a separate item. The roadmap lists Premier Support for Java 21 until September 2028 and Java 25 until September 2030, with Extended Support to September 2031 and September 2033. Freezing on an old patch to avoid a license question trades one risk for another.
What should a Java inventory include?
We start with one row per application and environment:
- Business owner, technical owner and how critical the system is.
- Runtime vendor, full version, architecture and install source.
- Container image tag and digest, where used.
- Build JDK, runtime JDK, framework, application server and build tools.
- Database drivers, monitoring agents, native libraries and certificate stores.
- Update source, license evidence, support contact, last patch date and rollback method.
Check running systems, not only laptops and repository settings. A pipeline can compile with one JDK while the deployed container runs another. Include scheduled jobs, integration workers and disaster-recovery copies. For packaged software, ask the supplier which runtimes it certifies, because a technically compatible JDK can still void their support.
Which path fits: upgrade, switch or stay?
Upgrade to Java 25
Choose this when your frameworks, agents, libraries and hosting support it and you can test the real business workflows. Pick the distribution on purpose instead of letting a developer's default download become the company standard. Set acceptance criteria for startup, memory, throughput and slow-request latency before you benchmark. Treat any speed gain as something to prove.
Keep Java 21 and change the distribution
This separates a vendor or license decision from a bigger migration. It still needs testing of trust stores, packaging, image contents, native dependencies and support terms. Adoptium lists Temurin 21 as available until at least December 2029. Amazon lists Corretto 21 end of life in October 2030. These dates belong to each vendor and can change, so recheck them before approval.
Stay on the current runtime for now
This can be reasonable when a certified vendor product blocks the move or a replacement is already funded. Require a maintained update source, documented entitlement, a named owner, a review date and an exit milestone. Our application retirement checklist helps when the plan is to switch the system off instead.
How do you prove a JDK change before production?
Oracle's JDK 25 migration guide recommends running the application on the new JDK, updating third-party libraries and build tools, and using jdeps to find dependencies on internal JDK APIs. It also warns that jdeps can miss APIs reached through reflection. A clean startup is not enough.
We organize testing around business behavior:
- Baseline: capture typical requests, batch results, resource use and known limits.
- Compatibility: exercise sign-in, database connections, file output, messaging, scheduled jobs and external APIs.
- Data correctness: compare currency and date formatting, time zones, sorting and exported documents.
- Operations: confirm health checks, logs, metrics, graceful shutdown and recovery.
- Release safety: roll out to a small slice first, with rollback triggers agreed in advance.
Keep the runtime change apart from feature work. A new JDK, framework rewrite and database move in one release makes failures hard to trace. If test tooling is part of the gap, our guide to choosing Selenium, Playwright or Cypress by test risk covers that decision.
How should Java patching work after the move?
Assign one person to watch the chosen vendor's advisories and confirm new builds reach your artifact repository. Then run the same pipeline every time: rebuild images, run regression tests, review results, approve, deploy and confirm the running version. Pinning an image digest helps reproducibility only if a planned process replaces it when a patch lands.
Track what the team can act on: applications with no owner, overdue patches, unsupported combinations and exceptions past their review date. A dashboard that only says "Java 21" hides the patch level that matters.
Frequently asked questions
No. It depends on the distribution, the build, how you use it and your agreements. Oracle JDK license terms do not apply to Temurin, Corretto or other vendors' builds.
It usually changes less, but it is not risk-free. Test application behavior, packaging, trust stores, integrations and supplier certification before you switch.
LTS is a sensible default when you need a long maintenance window. A short-lived release can work for teams that upgrade often and can keep pace with its update schedule.
The target distribution and version, the license position, the support arrangement, test scope, rollback plan, a named owner and the next review date. A version number alone is not a decision.
Sources
- Oracle: Java SE Support Roadmap
- Oracle: Java SE Licensing FAQ
- Oracle: JDK 25 Migration Guide, Preparing for Migration
- Eclipse Adoptium: Temurin Support
- Amazon Corretto FAQs
Plan your Java upgrade with evidence
If you are unsure which JDK your systems run, or a vendor product is blocking an upgrade, we can build the inventory, test plan and rollout with your team.
