- JDK 27's first release candidate slipped two weeks because of the JDK's first Critical Security Patch Update, according to InfoWorld contributor Simon Ritter.
- Ritter attributes the need for that patch to AI models getting better at finding vulnerabilities. This is his view, and he works for JVM vendor Azul.
- Teams should test whether they can apply a JDK security update mid-year, and review JDK 27's memory defaults, post-quantum TLS and Flight Recorder redaction settings.
When a patch moves the release train
Java gets a new version every September. Simon Ritter, writing in InfoWorld, calls this "metronomic regularity." This year the rhythm bent. Ritter reports that the first release candidate of JDK 27 came out two weeks late.
He ties the slip to the JDK's first CPSU, short for Critical Security Patch Update. He argues that AI models such as Anthropic's Claude Mythos have grown far better at spotting flaws and writing exploits, and that this made the CPSU necessary.
Two caveats belong here. The link to AI is Ritter's own assessment, and the article gives no vulnerability details to test it. Also, Ritter is Deputy CTO at Azul, which sells JVM products. He has also served on the OpenJDK Vulnerability Group.
The cause of the delay also rests on Ritter's account alone. He mentions it briefly and gives no further detail. One slipped date is a single data point, not a trend. Still, it shows what the idea looks like in practice. A security patch has just moved the schedule once for a platform that runs on a fixed yearly beat.
Why the calendar matters to your team
This section is our own reasoning, not a finding from the article. Teams that plan Java upgrades around the September date often tie testing windows, change freezes and staffing to it. A patch that arrives off-cycle can land on the people who keep those systems running. In this case the patch delayed a release candidate. The article does not say it hit systems already in production.
Ritter's advice is direct. Any Java shop that has not yet reviewed how it patches the JDK should do so now. The sensible question is not whether your team can upgrade once a year. It is whether it can take a security update in the middle of a quarter.
What JDK 27 changes inside the runtime
The release has nine JDK Enhancement Proposals (JEPs), the formal documents that define Java changes. Five are preview or incubator features still being refined. Ritter calls the release quiet on new features. Four items matter most to operators.
JEP 534 turns on compact object headers by default. Every Java object carries a small header of bookkeeping data, and the compact form makes it smaller. It was final in JDK 25 but needed a command-line flag. The JEP cites a 22% cut in heap space and an 8% cut in CPU use on the SPECjbb2015 benchmark. That is one benchmark, so measure your own workloads.
JEP 523 makes the G1 garbage collector the default everywhere. A garbage collector frees memory the program no longer uses. Until now, small environments with one CPU or under 1792 MB of memory used the older serial collector. Ritter says recent changes let G1 perform as well as the serial collector in all environments. Testing small containers after the upgrade is a sensible precaution, not a sign of a known problem.
Two security changes worth a closer look
JEP 527 adds post-quantum hybrid key exchange to TLS 1.3, the protocol that protects web traffic. Today's RSA and elliptic-curve encryption rest on maths problems that quantum computers could solve. Ritter notes that such machines are not readily available yet. He says criminals are already collecting encrypted data in case they can decrypt it later. That is his claim, and the article offers no figures. The change adds quantum-resistant algorithms to Java's standard network security layer.
JEP 536 has Java Flight Recorder redact sensitive data before it leaves the process. Flight Recorder is a built-in diagnostics tool. Its recordings can capture command-line arguments, environment variables and system properties. Those can hold secrets, access tokens and passwords. Ritter says command-line arguments control which information is redacted. The article does not describe the defaults, so check them and the available settings in the JEP.
This is a fair picture of where runtime security work sits. Some of it protects data in transit, and some protects what your own diagnostics expose.
Questions to put to your team
First, can we apply a JDK security update outside the yearly upgrade cycle, and how long would it take? Second, which of our services run on Java, and on which versions? Third, where are Flight Recorder files stored, who can read them, and have we checked the redaction defaults and settings in JEP 536? Fourth, which Java services terminate TLS, and are they ready to test hybrid key exchange?
One more point from the article. JDK 28 already has six targeted JEPs, including the first parts of Project Valhalla. Ritter plans to cover them closer to release. A quiet release and a larger one next year make a good moment to rehearse an off-cycle patch.
The lesson of this release is simple. A steady calendar is a convenience, not a promise, and a patch plan that depends on it has a gap.
Produced by the WebPulse Newsroom with AI assistance from the original reporting credited below, and checked against that source by our editorial review. How we use AI.
Original reporting: InfoWorld.
