Spring Framework for Java Enterprise

When we started building a new core system for an insurance company in 2008, we faced the classic dilemma: pure Java EE (EJB 3.0, JPA, JSF) or Spring Framework? We chose Spring. Four years and 200,000 lines of code later, we know it was the right decision.

Spring vs. Java EE — the eternal debate¶

Java EE 6 (approved in December 2009) made an enormous leap forward. EJB 3.1 is finally usable without XML hell, CDI brings dependency injection directly into the specification, and JPA 2.0 is a solid ORM standard. On paper, the reason for Spring almost no longer exists.

In practice, it’s different. Spring has a head start in ecosystem, documentation, and community. Spring Security is the de facto standard for authentication and authorization in the Java world. Spring Batch has no equivalent in Java EE. And most importantly — Spring lets you choose your application server. You can run on Tomcat, which is simple and lightweight, instead of a full Java EE server like WebSphere or JBoss.

Dependency Injection in practice¶

DI is the heart of Spring and the reason why code written with it is testable. Without DI, your service creates its own dependencies — and you can’t replace them with mocks in tests. With Spring, you declare dependencies and the container provides them.

@Service

public class ClaimService {

private final ClaimRepository repository;

private final NotificationService notifications;



@Autowired

public ClaimService(ClaimRepository repository,

    NotificationService notifications) {

    this.repository = repository;

    this.notifications = notifications;

}

}

Constructor injection (rather than field injection) is our standard. Dependencies are explicit, immutable, and the class is usable even without the Spring container — just instantiate it with new and pass in mocks.

Spring MVC for the web layer¶

JSF (JavaServer Faces) is the official Java EE web framework, but honestly — nobody likes it. The component-based model is cumbersome, the request lifecycle is complex, and debugging is a nightmare.

Spring MVC takes the request-based model approach (similar to Struts, but cleaner). A controller is a POJO with annotations, URL mapping is clear, and testing is trivial — MockMvc lets you test controllers without starting a server.

For the view layer we use Thymeleaf instead of JSP. Templates are valid HTML that a designer can open in a browser without a server. And unlike JSP, you don’t need a servlet container for rendering.

Transaction management¶

In enterprise systems, transactions are everywhere. Spring offers declarative transactions via the @Transactional annotation — the simplicity of EJB CMT (Container-Managed Transactions), but without the EJB container requirement.

Under the hood, Spring creates an AOP proxy that opens a transaction before the method and commits it afterwards (or rolls back on exception). Understanding propagation is important — REQUIRED, REQUIRES_NEW, NESTED. Incorrectly configured propagation is a common source of bugs that only manifest under load.

Our tip: always set readOnly = true for read operations. Hibernate then doesn’t need to do dirty checking and performance noticeably improves. On our system this resulted in a 20% reduction in read operation time.

Spring Security¶

Security in enterprise Java applications is a complex topic. Authentication against LDAP/Active Directory, authorization at URL and method level, CSRF protection, session management, remember-me… Spring Security handles all of this.

Configuration used to be notoriously complex (XML namespace with dozens of elements), but since version 3.1 it has significantly improved. Java config is more readable and your IDE helps with autocomplete.

In our insurance application we have role-based access control with a role hierarchy (AGENT → SUPERVISOR → ADMIN) and method-level security via @PreAuthorize annotations. Every endpoint is secured and an audit log records who, when, and what they did.

Testing — the main win¶

The greatest benefit of Spring isn’t any specific feature, but testability. On the project we have over 3,000 unit tests and 400 integration tests. They run with every build in Jenkins CI.

Unit tests are pure JUnit + Mockito — no Spring context, no server, they run in seconds. Integration tests use SpringJUnit4ClassRunner with an in-memory H2 database. The entire test suite finishes in 8 minutes.

Without DI and without Spring we would have a fraction of this coverage. And that fraction would be unreliable, because it would depend on external systems.

What we would do differently¶

• Less XML: We started with XML configuration (2008, Spring 2.5). Today we would go straight to Java config and component scanning.
• Spring Profiles earlier: Profiles for dev/test/prod environments save headaches. We introduced them only after a year.
• REST from the start: We started with SOAP web services (WS-* stack). Today we would go straight to REST + JSON.
• Maven instead of Ant: We migrated the build system to Maven only in 2010. Wasted time.

Summary¶

Spring Framework in 2012 is a mature, robust platform for enterprise Java development. Its key advantages — testability, flexibility and a rich ecosystem — outweigh the single drawback (it’s not a standard). For a new project we would choose Spring again, without hesitation.