Why I’m using Java EE

#javaee #jakarta monday, october 24, 2016

Just recently, after one of my sessions at JavaDay Kyiv I was asked by an attendee what the reasons were that I’m using Java EE. In the session I told 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:

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 backwards compatible (or fully compatible to other Spring components with different life cycles, 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 just used with each other right away — like Bean Validation together with CDI. That and the fast build times with small war-files made me considering Java EE as favorable choice more and more.

Especially since Java EE 7 when used together with Java 8 you can use that technology 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 specification 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 possible
Backwards compatible (that’s especially interesting for long-lived enterprise project), no surprises when updating a version

Conclusion

As always the choice of the technology depends 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 advice to go with one but not mix them together. IMO 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.

What are you thoughts and reasons for choosing specific technologies? Feedback is highly appreciated.

PS: Thanks Oleksandr for asking that question!

Found the post useful? Subscribe to my newsletter for more free content, tips and tricks on IT & Java: