In the last article, BrightCart got its first real feature: an endpoint that summarizes support tickets. The system prompt that powered it was a triple-quoted string sitting in a @Bean method. It worked, it was readable, and for one prompt it was completely fine. But I’ve been writing Spring AI applications long enough to know what happens next. One prompt becomes three. Three become a dozen. Someone wants the summary to mention the customer’s loyalty tier. Someone else wants a different prompt for priority tickets. Before long you’ve got string concatenation scattered across five service classes, nobody remembers which prompt is the good one, and changing the wording means a recompile and a redeploy. ...

Every team has its boilerplate. At clients, every new REST controller we write follows the same shape: a @RestController with a @RequestMapping, constructor injection (never field injection), a @Slf4j logger, ResponseEntity return types, proper HTTP status codes, and a matching service interface already wired in. Oh, and Lombok. Always Lombok. The first few times I asked Claude Code to generate a controller, I typed all of that out. Every time. A paragraph of instructions just to get the scaffolding right before the interesting work could begin. ...

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

Somewhere in articles 1 and 2, I kept writing this line and asking you to take it on faith: java chatClient.prompt().user(question).call().content(); It works. It reads nicely. And if you’re anything like me, the fact that it works without you understanding why has been quietly bothering you since article 1. Today we fix that. This article takes ChatClient apart — every method in that chain, every configuration option that matters, and the parts of the API we haven’t even touched yet. By the end, the fluent API won’t be a magic incantation anymore. It’ll just be… an API. A well-designed one, but still. ...

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