Java · Part IV

The Practice

If an agent writes the syntax, your job moves up a level: deciding the shape, and judging the result. Both are done in the vocabulary of Parts I to III. This page is how to use it.

What to delegate, what to own

Delegate freely	Own yourself, always
Syntax, imports, boilerplate	Where the transaction boundary is
Builder and mapping code	What is shared between threads, and why it is safe
Test scaffolding	Which tests are unit, slice or integration
Config wiring	What the module boundaries are
Library API lookup	Which queries a request issues
Refactoring mechanics	What happens when it fails twice

The pattern: delegate anything whose correctness the compiler or a test can check for you. Own anything whose correctness only shows up under concurrency, under load, or at 3am — because those are exactly the things that look fine in a diff.

A review checklist that finds real Java bugs

Read generated code against this. Every item is a failure from the earlier parts, and each one is invisible unless you go looking.

1. Is anything shared and mutable? A field on a singleton bean is shared by every concurrent request. Either it is immutable, or a concurrent type, or it is a bug.
2. Where does the transaction start and end? Point at the line. If a transactional method is called from inside the same class, the proxy is bypassed and the transaction does not exist.
3. How many queries does this issue? If a loop touches a relation, assume N+1 until proven otherwise.
4. Is an entity being returned from the API? That couples your schema to your contract and invites lazy-loading failures during serialisation.
5. What happens on the second delivery? Message consumers and retried calls must be idempotent.
6. Is an exception caught and logged and then execution continues? That converts a loud failure into a silent wrong answer.
7. Are resources closed on the failure path as well as the happy one?
8. Does config failure stop the boot? Better a crash at startup than a null at midnight.
9. Are timeouts set on every outbound call? A call with no timeout is a guaranteed outage waiting for a slow dependency.
10. Do the metrics have bounded tags? One tag with unbounded values is an outage in the monitoring system.

Questions that force the ideas out of an agent

Generated Java compiles and looks plausible; that is exactly the danger. These questions make the model state the things it usually leaves implicit, and they are the same questions a senior reviewer would ask you.

• "Which of these objects are singletons, and what state do they hold?"
• "List every SQL statement this endpoint issues, in order."
• "Where exactly does the transaction begin and commit? What propagation does it use?"
• "What happens if two requests run this at the same moment on the same row?"
• "What is the failure mode if this downstream call takes sixty seconds?"
• "Which of these tests would still pass if the behaviour were wrong?"
• "What does this look like on the tenth retry of the same message?"

An order to learn in

1. The process model. Long-lived, multi-threaded, shared heap. Everything else is downstream of this and it is the one that breaks PHP instincts.
2. The container. Beans, scopes, constructor injection, and what a singleton really implies.
3. Proxies. Once you know a proxy is what makes annotations work, half of Spring's mystery evaporates — and the self-invocation trap becomes obvious.
4. Transactions and the persistence context. The most expensive area to be vague about; also where most production incidents live.
5. Concurrency. Happens-before, then the tool ladder, then virtual threads.
6. The build graph. How to print it and read a conflict.
7. Observability. Wire it before you need it; it is how you learn what your program actually does.
8. Memory and GC. Last, and only to the depth of reading a heap dump — do not tune collectors you have not measured.

How to tell you have actually learned it

Not by writing code from memory — that is what the agent is for. You have learned it when you can do these without looking:

• Predict the queries an endpoint will run, then check and be right.
• Say why a bean exists and what would happen if it did not.
• Look at a class and say whether it is safe to share between threads.
• Point at the transaction boundary in unfamiliar code.
• Read a dependency tree and explain which version won.
• Choose between virtual threads and reactive, and defend it in one sentence.
• Look at generated code and name what it did wrong before running it.

← back to Part I

Written for someone who has an agent for the syntax and needs the ideas instead. Nothing here is a code sample on purpose — if you can name the mechanism, you can ask for the code and judge what comes back.