Over a million developers have joined DZone.
{{announcement.body}}
{{announcement.title}}

Why I'm Using Java EE (Instead of Spring)

DZone's Guide to

Why I'm Using Java EE (Instead of Spring)

The case is made for using Java EE 7 and 8 over Spring. Whether it's backward compatibility, the minimal configuration, or other benefits, here's what he has to say.

· Java Zone ·
Free Resource

Verify, standardize, and correct the Big 4 + more– name, email, phone and global addresses – try our Data Quality APIs now at Melissa Developer Portal!

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.

Developers! Quickly and easily gain access to the tools and information you need! Explore, test and combine our data quality APIs at Melissa Developer Portal – home to tools that save time and boost revenue. Our APIs verify, standardize, and correct the Big 4 + more – name, email, phone and global addresses – to ensure accurate delivery, prevent blacklisting and identify risks in real-time.

Topics:
java ,spring

Published at DZone with permission of

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}