Spring

What is it

Spring is the de facto standard framework for enterprise Java development. At its core is Inversion of Control (IoC) and Dependency Injection (DI)—instead of manually instantiating objects, you define what a component needs and Spring “injects” the dependencies at runtime. This creates loosely coupled, highly testable code. Spring Boot builds on this foundation with auto-configuration and embedded servers, letting you create production-ready applications with minimal setup.

My Opinion

Spring is the reason Java didn’t die. When Node.js and Python started eating the startup market, Spring Boot kept Java relevant by finally giving us “convention over configuration.” Before Spring, Java enterprise development was an XML-haunted nightmare. After Spring Boot, it’s actually enjoyable.

The Engine vs. The Car

Many developers treat Spring and Spring Boot as competing technologies—that’s a fundamental misunderstanding. Spring is the engine; Spring Boot is the car built around it.

Spring Framework provides the heavy lifting: transaction management, REST endpoints, security. But it requires manual configuration—every bean defined, your own server setup, version management hell. Spring Boot is an opinionated layer that uses auto-configuration to guess what you need. See a MySQL driver on your classpath? It configures a DataSource. It includes embedded Tomcat, so your app runs as a standalone JAR.

The “Black Box” Problem

The biggest criticism of Spring is that it’s heavy on magic. Auto-configuration works great until it doesn’t—then you’re debugging why @EnableAutoConfiguration decided to load 17 beans you didn’t ask for. The abstraction layer is thick, and when it leaks, it leaks hard. Understanding what Spring does under the hood requires reading source code, not just documentation.

The Startup Tax

Spring is heavy. A simple “Hello World” REST API takes 2-3 seconds to start and consumes 150-250MB of RAM. This is the JVM overhead plus embedded infrastructure: web server, thread pools, and hundreds of classes loaded for “just in case” auto-configuration.

For long-running services, this doesn’t matter. For serverless or cold-start scenarios, it’s terrible. The ecosystem has responded with GraalVM Native Images—compiling Spring Boot apps into native binaries drops memory to ~30MB and achieves near-instant start times. But native compilation has its own complexity tax.

The XML Myth

A common misconception: Spring was “the XML era” and Spring Boot is “the annotation era.” Wrong. Spring 3.0 introduced Java-based configuration years before Spring Boot existed. Many modern enterprises still use XML-based configuration with Spring Boot—XML allows configuration changes without recompiling code, making it a strategic choice, not a legacy mistake.

The Ecosystem Moat

This is why you choose Spring. The ecosystem is unmatched:

• Need Kafka integration? There’s a starter for that
• Legacy SOAP service? Spring’s got your back
• OAuth2 security? One annotation
• Batch processing? Spring Batch
• Cloud-native? Spring Cloud

The “batteries included” approach means you rarely write integration code. When something doesn’t work, there are thousands of Stack Overflow posts to help you.

The “Spring Way” vs. Idiomatic Java

Spring has its own conventions that sometimes fight against idiomatic Java. Heavy use of reflection and proxies can make debugging painful. The dependency injection container encourages patterns that feel like service locators. But once you drink the Kool-Aid, you realize the tradeoff is worth it for the productivity gains.

Conclusion

Spring is the default choice for Java enterprise development, and for good reason. The ecosystem, community, and developer experience are unmatched. Just be aware of the startup costs and know that when the magic fails, you’ll need to understand the internals. For Scala developers looking for something similar, you’ll be disappointed—nothing in the Scala ecosystem comes close.