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(). ...

Claude Code — Teaching It Your Standards with Skills In Part 2, we turned CLAUDE.md into a precision instrument. We wrote down our conventions, our architecture, our rules — and watched Claude Code go from producing generic boilerplate to code that could survive a code review. But here’s the thing I noticed after a few weeks of working this way: my CLAUDE.md was getting fat. It started small. Build commands, naming conventions, a few architecture rules. Then I added a section on how to generate a complete REST slice. Then testing patterns. Then a procedure for running database migrations with Flyway. Before I knew it, the file was 300 lines long, and every single line was loaded into every single session — whether Claude needed it or not. ...

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. ...

In Part 1, I showed you what Claude Code is and what it can do. You saw an AI agent that reads your project, writes code, runs your build, and fixes its own mistakes. Impressive stuff. But here’s the thing. If you just fire up Claude Code and start prompting, the output you get is… generic. It’s correct, sure. But it doesn’t know your team uses MapStruct instead of manual mapping. It doesn’t know your POST endpoints need authentication. It doesn’t know you measure everything with Micrometer and that a controller without metrics is considered incomplete. ...

I remember the first time I tried a GitHub Copilot suggestion in IntelliJ IDEA. It felt like magic. You start typing a method name, and suddenly the entire implementation materialises in grey ghost text. You press Tab, and — bam — it’s there. That was impressive. But it was still you doing the driving. In 2026, the landscape has shifted. Claude Code feels different. It’s less “autocomplete on steroids” and more “a colleague who sits next to you, holds the entire 1M token context of your codebase in their head, and then just… gets to work.” Let me show you what I mean. ...

Java 27 is currently in development. What is in there? Java 27 will be made up of a number of Java Enhancement Proposals (JEPs). 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. JEP 527 Post-quantum Hybrid Key Exchange for TLS 1.3 Introduces a hybrid key exchange for Java 27 that layers new quantum-resistant math (ML-KEM) on top of proven traditional encryption to ensure data remains secure. ...

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. ...

Java Pattern Matching: The Missing Piece (JEP 530) We have reached the 10th and final JEP of the Java 26 series. If you’ve been following Java for the last few years, you know the language has been on a massive “glow-up” journey. It was Project Amber that brought us records, sealed classes, and pattern matching. And this last one has been the stars of the show. It started as a way to stop writing those annoying casts after an instanceof, and it’s grown into a powerful tool for data-driven code. ...

Java’s Vector API: The Marathon Continues (JEP 529) The Vector API is a new addition to the Java standard library that allows you to perform vector operations on arrays in a single CPU cycle. If there were a Guinness World Record for the “Longest Incubating Feature in Java History,” the Vector API would be holding the trophy. With the arrival of JEP 529, the Vector API is entering its 11th round of incubation in JDK 26. ...

Bye-Bye Boilerplate: Say Hello to Java’s New “Lazy Constants” If you’ve ever had to initialize a heavy object only when it’s actually needed, you know the drill. You probably reached for the “Double-Checked Locking” pattern (which is easy to mess up) or the “Initialization-on-demand Holder” idiom (which is verbose). JEP 526 (Lazy Constants), coming as a second preview in JDK 26, is here to retire those old hacks. It introduces a first-class way to handle deferred initialization that is thread-safe, easy to read, and—best of all—lightning fast. ...