It was a Friday afternoon and I was in the middle of a long debugging session. I had been going back and forth with Claude Code for maybe forty minutes — adding context, correcting assumptions, exploring three different theories about why a JMS listener was silently dropping messages. The session was getting noisy. Old context from theories I’d already ruled out was still sitting there, cluttering the conversation. I didn’t know about /compact yet. ...

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

Intro In the previous article, we ran a Spring AI application in about twenty lines of Java. It worked. A ChatClient appeared out of nowhere, we called .prompt().user(...).call().content(), and Claude answered. That’s the magic of Spring Boot autoconfiguration — and also the danger of it. When things work without explanation, you’re fine right up until you need to debug something, customise something, or explain to a colleague what exactly is happening. Then you’re stuck. I’ve been there more times than I care to admit — staring at a NoSuchBeanDefinitionException at 4pm on a Friday, completely unable to explain why a bean that “should just be there” isn’t. (It was a missing property. It’s always a missing property.) ...

I still remember the moment it clicked — and the much longer stretch before it did. I’d been building Spring Boot applications for years. I knew the ecosystem. I knew how to wire beans, configure starters, and navigate the autoconfiguration magic without panicking. Then I started exploring Spring AI, and suddenly I was lost again. Embeddings. Vector stores. RAG pipelines. Advisors. ChatClient vs ChatModel. A wall of new terminology that felt completely disconnected from everything I already knew. ...

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 rampdown phase one and will reach general availability on September, 15th, 2026. The release will consist of 9 JEPs. What is in there? Java 27 will consist of these 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. ...