Ask “what version of Java is your core system on?” and few companies can answer on the spot. Usually they check with the maintenance vendor and come back a few days later with “it was Java 17”. The decision not to touch something that works is not, in itself, wrong.
That said, two things happened around Java in September 2026. One was the release of Java 27. The other was Oracle switching to monthly delivery of security patches. For the party commissioning the work, only the second one matters. The first is not, at least right now, something to decide on.
Java 27 is not a migration target for business systems
Java 27 was released on September 15, 2026 (US time). The first thing to establish here is that 27 is not an LTS (long-term support) release.
JDK 27 is the 18th feature release on the six-month cadence and receives updates until JDK 28 arrives in March 2027. In other words, its support period is about six months. Put a business system on it and the conversation about upgrading starts again half a year later.
Java long-term support releases come out every two years; the most recent LTS is Java 25, and the next is Java 29, expected in 2027. The version to plan a business system migration around is 25, not 27. Even if your maintenance vendor tells you “the newest version is out”, if they mean 27 there is no need to consider it urgently.
This structure — “the newest version and the version you should run are different” — is the same for .NET. The way to work backwards from support deadlines is organized in .NET 8/9 end of support and the business system migration decision.
What really matters is that patches went monthly
The second development has a direct effect on operations.
Until now, Oracle delivered security fixes in bulk through the quarterly Critical Patch Update (CPU). To that has been added a monthly Critical Security Patch Update (CSPU) that fills the gaps between quarters. CSPUs are delivered on the third Tuesday of each month, and for Java the actual distribution began in August 2026.
By Oracle’s own account, the reason for this change is AI. Vulnerabilities are now found faster with AI assistance, and fixes can be produced faster too, so a quarterly cycle leaves too long a gap. Indeed, cases such as Microsoft patching over 1,000 vulnerabilities in a single month have emerged, and the pace of finding and fixing vulnerabilities is rising across the industry.
The problem is the capacity on the receiving end.
Most business system maintenance contracts are built around the quarterly CPU. Four times a year, apply the patch, run it in the verification environment, and if nothing is wrong, promote it to production. When that flow becomes twelve times a year, you simply need three times the people and hours for verification.
Realistically, this is what happens.
- You cannot apply everything, so you triage by severity. Someone has to do that triage
- If you leave the triage to the maintenance vendor, you need to confirm whether that falls within the contract
- The patches you skipped accumulate and you revert to applying them together at the quarterly CPU. At that point, more changes land at once and verification gets heavier
So the move to monthly is as much about making a decision every month not to apply as it is about being able to patch more often. At companies where it is unclear who makes that decision, in practice nobody is making it.
Treat the changes in 27 as a rehearsal for 29
Even if you do not put 27 into production, it is worth knowing what is in it, because the changes landing here are likely to carry over into Java 29, the next LTS.
| Change | Impact on business systems |
|---|---|
| G1 GC becomes the default in all environments (JEP 523) | Small containers and servers will select a different GC than before. Existing memory tuning may stop having any effect |
| Compact object headers become the default (JEP 534) | In 64-bit environments, object headers shrink from 96 bits to 64 bits. This pushes heap usage down |
| Hybrid key exchange with post-quantum cryptography in TLS 1.3 (JEP 527) | A mechanism preparing for decryption by future quantum computers. In some cases compatibility with existing endpoints needs checking |
The first two are the ones likely to bite first in practice. When the GC default changes, the JVM tuning you have built up can lose its underlying assumptions. Putting Java 27 into a verification environment and watching its behaviour under the same load as today improves the accuracy of your estimate for moving to 29. Put the other way round, that is as far as 27’s usefulness goes.
On post-quantum cryptography there is no need to rush right now, but data requiring long-term retention is a different matter. It is time to settle on a policy.
Three things to check in your maintenance contract
In light of the move to monthly, here are the three things worth checking before your next contract renewal.
- Who decides whether a patch is applied. A contract that says only “security patches will be applied” is open to differing interpretations on a monthly cadence. Settle the severity threshold and how non-application is reported
- How far verification extends. At what level do you confirm behaviour after applying a patch? Full regression across all functions, or a check of the main paths? Running every function monthly is unrealistic, so the line needs to be drawn
- Whether cost scales with frequency. If the application work is billed per occurrence, going monthly triples it directly. It is safer to discuss whether it fits within an annual envelope, or a flat fee including the decision-making
Benchmarks for maintenance costs and how to read the breakdown are organized in the business system maintenance cost guide. When an external factor changes the cost structure like this, framing it as redefining the scope rather than negotiating a price increase tends to land better.
What to do next
Start by listing the Java versions your live business systems run on and their support deadlines. Your maintenance vendor can produce this. If you are on Java 17 or 21, the migration target for now is 25. Version 27 is irrelevant.
Then check how many times you applied a security patch in the last three months. If the answer is zero, application was not happening even before the move to monthly, and that is what to address before any conversation about versions.
GleamHub offers development, AI and automation consultations covering Java version migration planning for business systems, reviewing your patch application process, and redefining the scope of maintenance contracts. Because the approach depends on your current architecture and operating model, please get in touch through the contact form.
Sources
- Java 27 officially released: G1 GC becomes the default in all environments, plus hybrid key exchange with post-quantum cryptography for TLS 1.3 — Publickey
- Java 27 released — improved heap efficiency and a focus on safety — gihyo.jp
- Oracle begins delivering Java security patches monthly, citing AI accelerating vulnerability discovery — Publickey
- Transitioning Java to More Frequent Security Updates — Inside Java
- Oracle announces Java 27: post-quantum cryptography support for TLS 1.3, G1 GC as the default, and more — Mado no Mori
- AI-Assisted Discovery Helps Microsoft Patch More Than 1,000 Vulnerabilities in a Month — InfoQ
