Introduction

An ORM like JPA/Hibernate makes database access feel like working with plain objects. That is exactly the problem: a single innocent-looking loop can fire hundreds of SQL queries, and you won’t see it until production slows to a crawl.

This post covers the ORM traps that bite Java teams most often — starting with the notorious N+1 query problem — and the concrete techniques that fix them.

The N+1 Problem

Consider loading authors and printing their books:

Introduction

“Agent” has become the word for any program that calls an LLM more than once, which makes it a word worth being precise about. An agent, in the sense this post uses, is a loop: the model decides which tool to call next, your code executes it, and the result feeds back in — repeating until the model decides it’s done. That’s a genuinely different (and riskier) shape than a single request/response call.

Introduction

LLMs are usually associated with Python, but a great deal of production software — banking, enterprise backends, long-lived services — runs on the JVM, and those systems increasingly need to call language models too. Java’s strong typing and mature tooling are genuine assets here: they push you toward exactly the discipline reliable LLM applications require.

The core mindset is the same in any language: treat model output as a hypothesis to verify, not a fact to trust. This post covers the practices that make Java LLM applications production-grade, using Anthropic’s Claude and the official anthropic-java SDK.

Introduction

Fixing N+1 queries (see the previous post) gets your Hibernate app down to a handful of queries per request. The next bottleneck is what each of those queries costs once your tables have millions of rows — and that is almost always a question of indexing.

An index turns “scan every row” into “look it up directly.” Get the index wrong — or skip it — and a query that took 2ms in development takes 4 seconds in production once real data volume shows up.

Introduction

Most Java systems don’t fail because a single class was written badly. They fail because the boundaries between classes were drawn in the wrong place — a database library leaks into business logic, a payment provider’s SDK shows up in twelve unrelated files, and changing one third-party dependency means touching half the codebase.

Designing for change is not about predicting the future correctly. It’s about isolating what varies so that when it inevitably does vary — a new payment provider, a swapped database, a different message broker — the blast radius is one adapter, not the whole system.

Introduction

Error handling is where a lot of otherwise-good Java code quietly goes wrong. Exceptions get swallowed, null leaks across boundaries, and stack traces arrive with no context about what the program was trying to do.

Good error handling is not about catching everything. It is about being deliberate: fail fast on programmer errors, recover gracefully from expected failures, and never lose the information a future on-call engineer will need.

Introduction

A Java Dockerfile can be three lines and technically work — or it can be a 700 MB image that runs as root, rebuilds from scratch on every code change, and gets OOM-killed under load. The difference is a handful of well-understood practices.

This post walks through building Java images that are small, secure, cache-friendly, and container-aware.

Start From a Slim, Current JRE — Not a JDK

You need a JDK to build, but only a JRE to run. Shipping a full JDK bloats the image and widens the attack surface.

Introduction

Most Java codebases have plenty of tests and still get burned by production bugs. The problem is rarely quantity — it’s that the tests exercise the wrong things: they assert internal wiring instead of behavior, they mock away every collaborator until nothing real is left, or they cover the happy path ten times and the failure path zero times.

Good tests are fast, deterministic, and tell you something true about behavior. This post covers the practices that make JUnit 5 and Mockito tests actually earn their keep.

Introduction

Java is often discussed as a single programming language.

In reality, Java is part of something much larger: the Java Virtual Machine (JVM) ecosystem.

The JVM has become a powerful runtime for multiple languages, each solving different problems while sharing the same platform.

What Makes the JVM Special

The JVM provides:

• Platform independence
• Automatic memory management
• Just-in-time compilation
• Mature tooling and debuggers

Languages built on the JVM inherit these benefits without needing to reimplement them.

Introduction

For a long time, Java was associated with large, monolithic enterprise applications running on heavyweight application servers.

Then the industry shifted toward:

• Microservices
• Containers
• Cloud-native architectures
• Kubernetes

Many assumed Java would struggle to adapt.

Instead, Java evolved — and in many cases, thrived.

From Monoliths to Microservices

Early Java enterprise applications often relied on:

• Large EAR/WAR deployments
• Heavy application servers
• Centralized databases

Modern Java architectures look very different:

• Small, focused services
• Independent deployments
• Stateless APIs
• Horizontal scalability

Frameworks like Spring Boot dramatically simplified Java service development by removing boilerplate and enabling rapid startup.