Ilias Tsagklis

About Ilias Tsagklis

Ilias Tsagklis is a senior software engineer working in the telecom domain. He is an applications developer in a wide variety of applications/services. Ilias is co-founder and Executive Editor at Java Code Geeks.

Why I will continue to use Spring *and* Java EE in new Enterprise Java Projects in 2012/2013

Over one year passed since my technology decision making post and I am glad to see that I am still in perfect harmony with it. Some months ago I have written an answer to a nice blog of Kai Wähner about JEE vs. Spring. If view points don’t differ then where is the value add in a discussion? I do agree to many of Kai’s points. However, to me it’s not Java EE *or* Spring (like suggested in this recent post) and it’s not a matter of features ’cause in the end features are well sorted in both architectural options (and their corresponding ecosystems). If something is missing somebody out there already wrote a good library and put it open source. It’s also not a question of “heavy weight” or “light weight”.

After some years any framework will carry some dead freight due to downwards compatibility requirements. For those reasons this blog won’t be a technical essay about the what’s and why’s of Spring and Java EE. I think – in the first place – the whole issue comes down to the question where you want to place framework libraries that you use as development API to write your business applications: in the server library directories or with the WAR/EAR file in WEB-INF/lib.

 Figure 2: Simplified development architecture of Spring and Java EE applications

The biggest relevant difference in Spring and *pure* Java EE applications is that the development framework API in Spring applications is part of the Java application (WAR or EAR file) deployed to an arbitrary Java runtime. In contrast, pure Java EE applications only consist of business code and the application framework is part of the application server. Hence, the business applications directly work on application server APIs. Beside these pure scenarios a majority of todays Java enterprise applications use a mix of Java EE and Spring APIs. It’s possible to make a Java EE *or* Spring decision in almost any distinct subject matter (Web-Services, IoC-Container, GUI and so forth).

There are also pure runtime environments for Java EE and Spring applications: Java EE compliant servers (Redhat JBoss, IBM WebSphere, Oracle WebLogic) and VMWare’s vFabric tc Server. So on a green field one could choose pure Java EE application architecture vs. pure Spring application architecture. However, as explained, the most applications out there run a mix. I haven’t made an acedenic evaluation but I suspect that many applications run on a Java EE or Tomcat server environment with a Spring IoC container. Rather then using *only* Java EE or full blown Spring stack it’s just very common to use a well-balanced combination of mature Java EE and Spring API’s.

The strength of Java EE is the open standard established in a documented process by various parties. For this reason building applications for this platform is very popular, although many projects use only a little amount of Java EE API. Another important fact to notice is that every (wise) Java packaged software supplier supports the major Java EE platforms. As a result of all this many larger enterprises host Java EE servers in house anyway. Running Spring applications on Java EE servers is near-by then. This setup may provide benefits for enterprises with many dozens or even hundreds of Java applications in production.

1 – Migrating JEE servers is considerably easier because the applications use less server API *directly*.
2 – For the sake of little migration costs, most of the in-house clients will decide to migrate their business applications to current server versions.
3 – Less server generations in IT landscape, less local development environment generations due to little Java versions in production, simpler ALM solutions – all in all: manageable complexity and more homogeneous landscape.
4 – Fast response to new client requirements: if you need new (Spring) features you’ll only compile a new version of WAR/EAR files and deploy the stuff to an arbitrary Java runtime.
5 – The range of potential target runtime environments will be higher compared to Java EE full stack. Which means you may be “more” plattform independent.
6 – With Spring you can add smaller peaces of functionality to your applications or server environments (avoids: Snowball-effect).
7 – Compared to Java EE, the complete innovation cycle is faster (from the feature request to the usage in production).
8 – Spring enhancements are made according to actual real world client project requirements which ensures their practical applicability.
9 – Application development teams remain responsible for the application development stack and can decide flexibly which API fits the clients needs.

It’s difficult to achieve all these benefits in a pure Java EE development stack (some of them address conceptual problems in Java EE). One possible option may be to modularise JEE application server architecture. Modularization as a standard, like in Java SE. It may also be valid to think about the release processes (i.e. JCP).

As I said previously, I do believe it’s never been JEE *against* Spring in general ’cause these two options work in harmony together in so many instances. Today it’s still a valid option to use both, Spring and Java EE, like explained in my other blog entry. I believe the vital discussion in the past is more about the programming model for our business applications: CDI vs. Spring IoC and JSF vs. Spring MVC. The debate is also often an emotional one about “like EJB” or not (for historical reasons). Furthermore, it’s a lot about *real* independence of your business applications from the underlying platform (server, operating system, hardware). For example: we use EJB as integration technology but the business applications don’t know about it. The key to platform independence is not using either Java EE or Spring but: making sound decisions which APIs to use *directly* in your business applications programming model. And sometimes it may be better not to use some application-server-lib-directory derived ones.

Reference: Why I will continue to use Spring *and* Java EE in new Enterprise Java Projects in 2012/2013 from our JCG partner Niklas.

Do you want to know how to develop your skillset to become a Java Rockstar?

Subscribe to our newsletter to start Rocking right now!

To get you started we give you two of our best selling eBooks for FREE!

JPA Mini Book

Learn how to leverage the power of JPA in order to create robust and flexible Java applications. With this Mini Book, you will get introduced to JPA and smoothly transition to more advanced concepts.

JVM Troubleshooting Guide

The Java virtual machine is really the foundation of any Java EE platform. Learn how to master it with this advanced guide!

Given email address is already subscribed, thank you!
Oops. Something went wrong. Please try again later.
Please provide a valid email address.
Thank you, your sign-up request was successful! Please check your e-mail inbox.
Please complete the CAPTCHA.
Please fill in the required fields.

2 Responses to "Why I will continue to use Spring *and* Java EE in new Enterprise Java Projects in 2012/2013"

  1. Jirka Pinkas says:

    me too :)

  2. Liyu Wang says:

    In your code, do you extends classes from Spring, or annotated with Sprint Special annotations? I guess that’s the problem, it’s like cancer, later you will find it spread everywhere, and there is no way you can get out from Spring, or even worse, it’s hard to migrate to new version (some classes are gone in new version), and I remember year 2009, Spring tried to change their license, not sure when will they do that again.

Leave a Reply


four × 9 =



Java Code Geeks and all content copyright © 2010-2014, Exelixis Media Ltd | Terms of Use | Privacy Policy | Contact
All trademarks and registered trademarks appearing on Java Code Geeks are the property of their respective owners.
Java is a trademark or registered trademark of Oracle Corporation in the United States and other countries.
Java Code Geeks is not connected to Oracle Corporation and is not sponsored by Oracle Corporation.
Do you want to know how to develop your skillset and become a ...
Java Rockstar?

Subscribe to our newsletter to start Rocking right now!

To get you started we give you two of our best selling eBooks for FREE!

Get ready to Rock!
You can download the complementary eBooks using the links below:
Close