Spring and Java, Refreshed

Java was one of my first serious languages. At university I wrote Java and Kotlin for coursework and projects, including image-processing work like a seam-carving algorithm (content-aware resizing that removes the lowest-energy paths through an image) (Image Analysis Fundamentals). In March 2021, in my final year, I wrote a short explainer: what Spring is, why Spring Boot exists, what inversion of control and beans mean, and how a typical n-tier architecture keeps layers apart. It was a student’s summary, accurate as far as it went.

Five years later I’m working alongside Java services, on the front end of a trading platform at a fintech. I’m not writing Java day to day right now, but I want to understand the back end properly rather than at arm’s length. This is the refresh.

What still holds from 2021

Spring is a dependency injection container with batteries. Objects declare what they need; the container builds and wires them. That makes classes easier to test (swap a real dependency for a fake) and keeps construction logic out of business logic.

Beans are just objects the container manages. Annotate a class as a @Service, @Repository or @RestController, and Spring creates it (usually as a singleton) and injects it where it’s needed. The stereotype annotations also document the role of each class.

Layers keep concerns apart. Controller → service → repository is still the default shape. Each layer knows only about the one below it, which keeps HTTP details out of business rules and SQL out of controllers.

Spring Boot is the opinionated path. My post called it convention over configuration with production-grade features built in. That’s exactly right: auto-configuration, embedded servers, health and metrics endpoints. It’s a golden path for Java services, years before I had that phrase.

What I’d add now

• Constructor injection, always. Inject dependencies through the constructor rather than fields. Dependencies become explicit, objects are immutable, and tests don’t need the container.
• Configuration is part of the API. Profiles and typed configuration properties decide how the same code behaves in each environment. Treat them like code: reviewed, versioned, documented.
• Observability comes nearly for free. Spring Boot’s actuator endpoints and metrics integrations mean health checks, readiness probes and traces are a dependency away. Use them from day one (Observability).
• The API contract matters more than the framework. Most of my real work with back-end teams has been at the boundary: OpenAPI contracts, error shapes, pagination, and what a request body is allowed to mean (REST API Design Trade-offs: Bulk Deletes, Request Bodies and Cancellation, API Modelling).
• Money needs BigDecimal. Never double for prices (Let the Server Do the Money Maths).

How it compares with what I know

Coming from Node, the contrasts are useful:

	Node.js	Spring on the JVM
Concurrency	One event loop, async I/O	Thread per request by default; virtual threads in modern Java
Structure	Bring your own	Strong conventions: layers, DI, annotations
Typing	TypeScript, erased at runtime	Static types at runtime too
Strength	Fast I/O-heavy services, shared language with the front end	Large domains, long-lived services, a deep enterprise ecosystem

Neither is better in general. Spring’s structure pays off as a domain and team grow; Node’s simplicity pays off for small, I/O-heavy services (The Node.js Event Loop, Streams and Backpressure).

What I’m learning next

Honestly, this is where my knowledge is thinnest, and I’m working on it: JPA and transactions, how Spring handles concurrency with virtual threads, testing with Testcontainers against a real database, and reading production services rather than tutorials. It’s part of a wider plan in From UI Lead to Backend Lead: A Learning Path.

---

Originally written in 2021 → What is Spring - Java?