Why Should We Dump Java EE Standard?

Prologue

I never thought that I have to write about this topic again, but I have to since a couple months ago I have to justify a decision of using Spring Framework in an enterprise environment. The decision to be made was whether we are going for Java EE or using Spring Framework. The constraint was very clear:

• We need to support both batch and web apps.
• For web apps we only can use an old OAS (Oracle Application Server) with Java EE 1.4.
• Commercial support has to be available for the framework and the runtime environment.
• We are going to update the app server for Java EE 6 or 7 soon, so it should be possible to have a smooth migration.
• We would like to minimize the use of our home grown frameworks.

Still there was such a quarrel in the team because there are already some Java EE web apps run in OAS upgraded with JBoss Weld CDI 1.0. Normally JBoss Weld 1.0 won't run out of the box in OAS but with some patches we got it run. The problem with all those web apps is we had a lot of our own CDI extensions to fulfill enterprise features (declarative transaction management for services, caching, security) which already a part of Spring Framework a long time ago.

So it's time to google this topic "Java EE vs. Spring Framework" to see whether the dispute between them still exists.

Spring Framework Bashing 2012 and 2013

I found in Google a lot of Spring Framework bashing in years 2012 and 2013. There are some of blogs and articles saying that with the existence of Java EE - especially Java EE 7 - we don't need or should avoid Spring Framework. One of the most controversial article is this one: Why is Java EE 6 better than Spring? Luckily there are also some counter parts like this one: Java EE a tough sell for Spring framework users and this one Java EE vs Spring. Or: What is a standard?

So the topic is still hot!

Base on these discussions I need to make my own picture so let's get the two important aspects of enterprise application development: programming models and runtime environments.

Programming Models

Following enterprise application types should be supported from both stacks Java EE and Spring Framework:

• Web apps
• Batch apps

At last Java EE 7 supports both application types. Although the support of batch apps is still very young you should be able to define centralized business logic and can use it in both web and batch apps. The biggest problem I see with Java EE 7 so far are: 

• Since Java EE 7 and JTA 1.2 business logic component with transaction demarcation does not need to be an EJB component  anymore. But what about asynchronous method execution? For this purpose you still need Message Driven Beans (MDB) in EJB container. So EJB is still alive. This is where Spring Framework has its advantage. Everything like business logic components with asynchronous method execution and utilities is always POJOs, no different at all and it is available today. The counterpart of MDB is MDP (Message Driven POJOs) in Spring Framework.
• Security mechanism like authentication and authorization in Java EE 7 (JAAS) is still inflexible. If you use JAAS it is dependent on the chosen Java EE container. In contrary Spring Security is flexible and you can use it in all runtime environments available. The good news is that Spring Security can be integrated easily in Java EE 7 apps.  
• Since Spring Batch 3.x supports Java EE 7 batch standard and this framework is the longest batch framework available in the market you maybe will use Spring Batch as your Java EE batch implementation. It is an additional complexity in case I would use Spring Batch 3.x and I need to reuse business logic components written in EJB. Do I have to run my Spring Batch app within an EJB or Java EE container? Using pure Spring Batch makes everything simpler and easier.

Runtime Environments

Application server is the platform or the runtime environment where your Java EE applications can be deployed and executed. Looking at the Java EE application servers market you will notice that following has happened last year:

• 2013 Oracle pulled out OSS Java EE server Glassfish's commercial support. 
• OSS Java EE server Apache Geronimo is going nowhere, because IBM pulled out the commercial support for Geronimo.

So actually the platform where you can run Java EE applications is getting very few:

• Open Source application server with commercial support and reasonable price can only be found from JBoss / Wildfly and TomEE. Also a Java EE batch app needs a Java EE container.
• Apps based on Spring Framework can run everywhere (pure Servlet or Java EE containers like Jetty, Tomcat, VMware vFabric tc Server, now Pivotal tc Server, JBoss, Wildfly, TomEE) as long as your apps can access the implementations of services like JMS, transaction and cache. Spring Batch apps can run just within the plain Java SE.

Your Options

So in 2014 if you ever need to start an enterprise project what kind of enterprise platform will you use? If you want to write easy, secure enterprise apps (web and batch) with a single Java programming model which can be executed in many runtime environments, Spring Framework is still the one and only one choice you have.

The Problem with Java EE and My Solution: "One Runtime Environment with Standardized APIs and Simple Implementation Dependencies"

The idea to standardize some mechanisms using Java API is fine. It is good to standardize persistent mechanism with JPA, it is good to standardize dependency injection with CDI, messaging with JMS, Batch programming model with JSR-352 and others. What we don't need is the umbrella standard Java EE which puts a lot of those APIs together. Take a look at this page to see the content of Java EE. So what do we actually need?

• We only need one runtime enviroment standard. That is what we know today with Servlet container (Tomcat, Jetty and others). This is the one and only application server or operating system we need for our enterprise applications.
• We have all those standardization of APIs like JPA, JMS, CDI, Batch and others. The specification of those APIs should be completely loosely coupling. At the end as an end user you want to mix and match those APIs as you need them. The implementation of those APIs can be done like today through a normal framework implementation just like Hibernate (JPA), ActiveMQ (JMS), JBoss Weld (CDI), Spring Batch (Batch) and others.

That's it! No need to have those Java EE runtime environments like JBoss, Weblogic or Websphere. Of course they can still bundle all those frameworks together like what they already have done today but the most important point is actually that you can mix and match the implementations with different specification versions. Today it is impossible to do so. If you have a Java EE application server which supports Java EE 1.4 it is almost impossible to use JPA 2.1. 

Also if you have a lot of web and batch apps in production you cannot update all of them at once. Update has to be planned carefully. If you have Java EE 1.4 container in production you will stick to it in long term, since your traditional operation won't accept if you want to use different kind of containers for example Java EE 1.4 and Java EE 7 in production. If you want to move to a new Java EE 7 container you need to migrate all of your web apps at once and this is in a normal enterprise situation almost impossible. You can only update a web app within a project and you have limited resources to execute your project. So to use just a simple container and put all the implementation dependencies in the web app is the way to go. In this case you can use up-to-date APIs in some web apps. You don't need to update all the web apps just to be able to use up-to-date APIs in some new web apps. 

To conclude: the umbrella Java EE specification which contains all those APIs also makes everything more complex and makes update to a newer version of APIs very slow. 

Spring Framework supports the idea of one runtime environment and mix and match APIs since the beginning:

• You can use any runtime environments or containers which supports Servlet specification like Tomcat, Jetty or JBoss or others.
• You can mix and match all those standardized APIs like JPA, JMS, Batch (JSR-352), CDI (not complete but some of the specs like JSR-330 and JSR-250). 
• To use the APIs you have to include the implementations of the API specifications by yourself using standardize dependency mechanism for Java.
• You get a lot of nice helpers to "glue" APIs together to build a nice programming model on the top.

So the ideal situation would look like this picture below:

• Web app: the runtime environment (Web Container) does not include all the APIs implementations. The web app needs to include the dependencies by themselves (WEB-INF/lib directory).
• Batch app: no special runtime environment, just standard JVM. The batch app needs to include the dependencies by themselves (-classpath in Java execution parameter). 

Epilogue

In my opinion the enterprise development in Java has to go in the direction above:

• Drop the umbrella standard Java EE.
• Concentrate on one and only one runtime environment specification, the Servlet specification.
• Concentrate on APIs standardization like JPA, JTA, JMS, CDI, Batch and others and make them loosely coupled. Let the version of the APIs to be used mixed and matched.
• Use the standard dependency mechanism of Java to include the implementations within the web and batch apps.
• Don't forget the Security APIs, just copy them from Spring Security analog to Batch APIs using Spring Batch.

So at the end as an end user we have one and only one runtime environment (container). The rest is just standardized APIs (JPA, JMS, CDI, Batch, Security) with their implementations (Hibernate, ActiveMQ, Spring DI, JBoss Weld, Spring Batch, Spring Security) which can be used mixed and matched as you need them. With this style you can update the version of particular specification without having to update the whole runtime environment and all the APIs in one step. A new developed app can use the up-to-date APIs and their implementations. Update of older web and batch apps can be planned carefully without the need to update all the apps at once.

At the end we chose Spring Framework. We will use all available standardized APIs with the best implementations we can get. To be able to mix and match the version of APIs in each web and batch app we will manage the dependencies within the apps itself using standardize Java mechanism.


Updates: 

• 27.06.14: The term should be Java EE instead of JEE. Please see: http://goo.gl/8xfMsJ and http://goo.gl/NnCHy4
• 27.06.14: In the mean time you can follow discussions about this topic at: JavaLobby (http://goo.gl/KmqeWm) and TheServerSide (http://goo.gl/oQmWRG)