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 JEE 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 JEE 1.4.
- Commercial support has to be available for the framework and the runtime environment.
- We are going to update the app server for JEE 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 JEE 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 "JEE 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 JEE - especially JEE 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.
To conclude: the umbrella JEE specification which contains all those APIs also makes everything more complex and makes update to a newer version of APIs very slow.
In my opinion the enterprise development in Java has to go in the direction above:
- Drop the umbrella standard JEE.
- 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.
The full story can be found here: http://lofidewanto.blogspot.de/2014/06/why-should-we-dump-jee-standard.html