Java 27

Nine JEPs. Nine separate articles. Somewhere around March I sat down to write a quick overview post for Java 27, and here we are in the middle of September still talking about it. Java 27 is officially released. So let’s zoom out. If you’ve been following along JEP by JEP, some of this will be a refresher. If you haven’t, and you just want to know what’s actually changing when you type java -version from now on, this is the post for you. ...

Java 27 was released on September, 15th, 2026. The release consists of 9 JEPs. What is in there? Java 27 consists of these JEPs. Overview Sums up all the changes in this release, a summary of the articles below. JEP 523 G1 becomes the default GC everywhere Simplifies Java’s garbage collection behavior by making the G1 Garbage Collector the default choice across all hardware, removing the old rule where small or single-core machines would automatically fall back to the Serial collector. ...

G1 Garbge Collector, Always. If you’ve ever wondered which garbage collector the JVM actually picked for you when you didn’t tell it which one to use, the answer was always a little annoying: “well, it depends.” That “it depends” is exactly what JEP 523, targeting JDK 27, gets rid of. From now on, when you don’t specify a collector on the command line, the JVM always picks G1. No exceptions, no hardware-dependent surprises. Let me walk you through what’s changing and — more importantly — whether you should care. ...

Java 26 has just been released! (depending on your timezone), but work on Java 27 is already on the way. The first JEP of the new release is JEP 527: Post-Quantum Hybrid Key Exchange for TLS 1.3. JEP 527 (Post-Quantum Hybrid Key Exchange for TLS 1.3) is a Java enhancement designed to protect your internet communications from future quantum computers. Here is the breakdown in easy terms: 1. The Problem: “Harvest Now, Decrypt Later” Today, when you connect to a website (using HTTPS/TLS), the “key exchange” that secures your connection uses math (RSA or Elliptic Curve) that is very strong for current computers but could be cracked by a powerful quantum computer in the future. ...

Third Time’s the Charm: Lazy Constants Get a Trim and a New Trick Back in the Java 26 series, I walked you through JEP 526 and the (then) second preview of the Lazy Constants API. If you missed it, the short version is this: Java finally got a clean way to do deferred immutability — fields that initialize on demand but, once set, are treated by the JVM as if they’d been hard-coded constants. No more double-checked locking. No more holder idioms. Just LazyConstant.of(...) and a .get(). ...

If you’ve been following the evolution of Project Loom, you’ll know that Structured Concurrency has been on quite a journey. It started as an incubator module in JDK 19, became a preview API in JDK 21, and has now re-previewed five more times since — JDK 22, 23, 24, 25, and 26. JEP 533 is the seventh preview, targeting JDK 27, and this time the changes are meaningful enough that it’s worth taking a proper look. ...

Same Feature, Fifth Time Around If you read my JEP 530 post at the tail end of the Java 26 series, this one is going to feel familiar. Very familiar. JEP 532 is the fifth preview of “Primitive Types in Patterns, instanceof, and switch”, now targeting JDK 27. And here’s the honest headline: nothing has changed. No new syntax, no removed methods, no behavioural tweaks. The JDK team looked at JEP 530, decided it was in good shape, and re-proposed it as-is to bake for another release cycle. ...

A few years ago, a colleague of mine was convinced that a memory leak had crept into one of our microservices. The heap was consistently at 70% after startup — before a single request had been processed. We profiled it, combed through the GC logs, and eventually concluded that no, nothing was leaking. It was just object overhead. Lots of small objects, each carrying its overhead around like a briefcase it didn’t need. ...

A few years back, someone on my team attached a .jfr file to a vendor support ticket. Nothing unusual — Flight Recorder is the go-to tool when you need to show “here’s what the JVM was actually doing.” Except that recording also happily included the database password we’d passed in as a -D system property on startup. Nobody noticed until the ticket had already left the building. That’s the problem JEP 536 fixes. It’s not glamorous. It won’t make a conference keynote slide. But if you’ve ever shipped a JFR recording to a vendor, uploaded one to a shared bucket, or attached one to a bug report, you’ve probably leaked something you didn’t mean to. ...

Somewhere in one of my customers repo there’s a private method that parses -----BEGIN PRIVATE KEY----- blocks by hand: strip the header, strip the footer, Base64-decode what’s left, hand the bytes to a KeyFactory, hope you picked the right algorithm. I wrote something almost exactly like it years ago. It wasn’t hard. It was just the kind of tedious that makes you wonder why the JDK never gave you this for free. ...