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.

Related Whitepaper:

Functional Programming in Java: Harnessing the Power of Java 8 Lambda Expressions

Get ready to program in a whole new way!

Functional Programming in Java will help you quickly get on top of the new, essential Java 8 language features and the functional style that will change and improve your code. This short, targeted book will help you make the paradigm shift from the old imperative way to a less error-prone, more elegant, and concise coding style that’s also a breeze to parallelize. You’ll explore the syntax and semantics of lambda expressions, method and constructor references, and functional interfaces. You’ll design and write applications better using the new standards in Java 8 and the JDK.

Get it Now!  

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


6 + = nine



Java Code Geeks and all content copyright © 2010-2014, Exelixis Media Ltd | Terms of Use | Privacy Policy
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.

Sign up for our Newsletter

20,709 insiders are already enjoying weekly updates and complimentary whitepapers! Join them now to gain exclusive access to the latest news in the Java world, as well as insights about Android, Scala, Groovy and other related technologies.

As an extra bonus, by joining you will get our brand new e-books, published by Java Code Geeks and their JCG partners for your reading pleasure! Enter your info and stay on top of things,

  • Fresh trends
  • Cases and examples
  • Research and insights
  • Two complimentary e-books