JDD2014: Spring 4, Java EE 7 or Both? (I. Grimstad)

### Overview In this presentation at JDD 2014, consultant Ivar Grimstad compares Spring Framework 4 and Java EE 7, analyzing their evolution, feature sets, architectural differences, and how they interact when combined in enterprise applications. The talk walks through the historical trajectory of both ecosystems—from the early complexities of J2EE to the developer-friendly improvements in Java EE 5 through 7, alongside Spring's rise as an alternative that has now reached version 4. Grimstad presents live code examples to demonstrate the mechanics and pitfalls of integrating Spring components inside a Java EE application, as well as incorporating Java EE components within a Spring-based application.

### Key Topics - **Evolution of Enterprise Java and Spring**: A review of J2EE's initial complexity, the emergence of Spring in 2002–2004, and the modernization of Java EE (culminating in Java EE 7) focused on developer productivity, HTML5 support, and enterprise features. - **Spring 4 Features**: Overview of improvements including enhanced documentation on spring.io, Java 8 compatibility (supporting `@Repeatable`, lambda expressions, and method references via callback interfaces), core container updates with generic injection qualifiers, `@RestController` for REST endpoints, WebSocket and STOMP messaging support, and caching enhancements. - **Java EE 7 Capabilities**: Updates highlighting lighter configuration without mandatory `web.xml` or `beans.xml`, simplified EJBs, JMS 2.0 API cleanups, batch processing, JSON processing, and WebSocket support across certified application servers (GlassFish 4.0.1, WildFly 8.1, and TmaxSoft). - **Architectural Contrasts**: Java EE relies heavily on the underlying application server container to implement specifications, while Spring packages its context and container directly inside the application artifact. - **Cross-Framework Integration**: Hands-on techniques using CDI producers to expose Spring-managed beans within Java EE, and conversely using `@EJB` annotations or Spring bean definitions to ingest Java EE components into Spring.

### Technical Details Grimstad demonstrates both frameworks using simple REST counter applications: - **Integrating Spring into Java EE**: When adding a Spring component with `@Autowired` dependencies into a Java EE application, a CDI producer (`@Produces`) must not simply instantiate the object directly via `new`. Direct instantiation bypasses Spring's lifecycle, causing autowired dependencies to fail or produce incorrect results. Instead, the producer must initialize an `AnnotationConfigApplicationContext`, register the configuration class, refresh the context, and retrieve the bean explicitly so that Spring manages the dependency graph. - **Integrating Java EE into Spring**: When bringing a Java EE component (such as an EJB) into a Spring application, injecting it requires accessing the container using `@EJB` or configuring a Spring bean definition. If an EJB does not rely on enterprise container services, Spring can manage it as a standard bean; however, if the bean strictly relies on EJB container-provided functionality (such as transaction management), letting Spring take over can break expected container behavior.

### Takeaways Grimstad emphasizes that while Spring 4 and Java EE 7 solve similar problems and have substantial feature overlap, mixing both frameworks in a single project should generally be avoided. Java EE provides leaner WAR packaging and faster deployments due to shared container dependencies, whereas Spring offers portability by packaging its own context. If integration is unavoidable, Grimstad advises hosting Spring components inside a Java EE application rather than injecting Java EE components into Spring, and always ensuring that beans remain managed by their native runtime context.