Just recently, after one of my sessions at JavaDay Kyiv, I was asked by an attendee what the reasons were for my use of Java EE. In the session, I mentioned that in the past, I was also a heavy user of Spring.

Actually, I always enjoyed programming in Spring, and I liked the declarative programming model with annotations and the fact that the technology evolves quite fast. I used Spring up to version 4 in real-world projects, and we always tried to use the latest approaches — like @RestControllers, or Java-based configuration back then.

Besides the fact that Spring offered a great developer experience, I didn’t like a few things about it:

• There's quite a lot of configuration needed (XML, then Java-based config, Database setup/transaction managers), which has to be changed quite often.
• Longer build times (as the implementation is shipped in the deployment artifact) — we mostly deployed a fat-war on a Servlet container.
• Not always backward compatible (or fully compatible with other Spring components with different lifecycles, like Spring Security) when updating versions.

Besides Spring, I’ve been also using a lot of Java EE — depending on the project. What I especially liked about Java EE was the powerful dependency injection provided by CDI and the fact that the technology within the EE umbrella can be used with each other right away — like Bean Validation together with CDI. That and the fast build times with small war-files made me consider Java EE as the favorable choice more and more.

What's really sold me is the fact that Java EE 7 can be used with Java 8 without any other (technically-reasoned) dependency. With the convention-over-configuration and just-mix-and-match-what-you-like approaches, it offers a productive and, I think, really enjoyable developer experience.

So, as of today, my main reasons for favoring Java EE as an enterprise framework — it always depends on the project and the use-cases — are:

• Use different specifications together with each other seamlessly.
• Zero to minimal configuration, convention-over-configuration approaches.
• CDI’s powerful and flexible programming model.
• Separation of business code from framework implementation (also see another blog post).
• Very short build, transfer, and deployment times are possible.
• Backward compatible (that’s especially interesting for long-lived enterprise projects) and no surprises when updating a version.

Conclusion

As always, the choice of the technology depends on what you’re trying to achieve and how familiar you and your colleagues are with that technologies. The question is not whether A is better or worse than B but rather what the strengths and weaknesses are and when to apply them.

No matter if you’re using Spring or Java EE, I would, in general, advise you to go with one but not mix them together. In my opinion, it doesn’t make a lot sense to either deploy Spring on an EE application server or to use Java EE specific technology in a Spring stack, which is already covered by another Spring-specific component, respectively.