The question comes up often. It came up in my new project in November 2011, too. I will use Java EE (JEE) instead of the Spring framework in this new Enterprise Java project.
I know: Several articles, blogs and forum discussions are available regarding this topic. Why is there a need for one more? Because many blogs talk about older versions of Java EE or because they are not neutral (I hope to be neutral). And because many people still think thank EJBs are heavy! And because the time has changed: It is Java EE 6 time now, J2EE is dead. Finally! Finally, because not only JEE 6 is available, but also several application servers (not just Glassfish as reference implementation). I do not want to start a flame war (too many exist already), I just want to describe my personal opinion of the JEE vs. Spring „fight“…
Therefore, I think it is very important to start with a short overview and history of both alternatives. Afterwards, I will list the differences of both and explain why these differences lead me to JEE instead of Spring for most new Java projects. I am explicitly talking about new applications. If you have to extend an existing application, continue using the existing framework!
One more disclaimer: I am talking about mission-critical Enterprise Java applications. I am not talking about a little internal application or other uncritical stuff. I also would prefer using a combination of Scala, Groovy and Clojure persisting to a NoSQL database while being deployed at a PaaS cloud service such as JBoss OpenShift or VMware CloudFoundry…
First, I want to summarize some general information about JEE and Spring:
J2EE was horrible. So much XML configuration, so many interfaces, and so lame application servers. This is why the Spring framework was created. It solved many problems of J2EE. It was lightweight, easy to use, and applications could be deployed in a web container (such as Tomcat) instead of a heavy J2EE application server. Deployment took seconds instead of 15 minutes. Unfortunately, JRebel did not exist at that time. The Spring framework is no standard as J2EE, nevertheless it became very widespread and an large community arose.
Everything started with a little shortcut change. J2EE was dead. The new shortcut was JEE. JEE 5 was born in 2006. It „stole“ many good, lightweight ideas such as „convention over configuration“ or „dependency injection“ from Spring and other frameworks. Yes, JEE application servers still were heavy, and testing was almost impossible. Nevertheless, developing JEE applications was fun with JEE 5. You did not have to write 20 interfaces when creating an EJB. Wow, amazing!
Then, in 2009, JEE 6 was released. Development is so easy. Finally! For example, you have to add only one annotation and your EJB is ready! Of course, the developers of the Spring framework did not sleep. Much new stuff was added. Today, you can create a Spring application without any one XML file as I have read in a „No Fluff Just Stuff“ article some weeks ago. Besides, several really cool frameworks were added to the Spring stack, e.g. Spring Integration, Spring Batch or Spring Roo.
Today (November, 2011), both JEE and Spring are very widespread and have a large community. Much information is available for both, e.g. books, blogs, tutorials, etc.
So, after I have described the evolution of JEE and Spring, why will I use JEE in most new Java projects?
A decision must be made. Which alternative to use in new projects? Let’s look at the pros and cons of both. I will add a „BUT“ to the Spring advantages – these „BUTs“ are the reason why I prefer JEE to Spring.
BUT: JEE application servers are not as heavy as they were some years ago. Besides, the JEE web profile can be used, too. You do not have to use a Tomcat or Jetty to be lightweight!
BUT: You can add such a library to a JEE project without problems. You can also add other Spring libraries such as JDBCTemplate or JMSTemplate (which help reducing some boilerplate code) if you want.
BUT: In most projects you do not need this flexibility or power. If you do need it, then use Spring, not JEE – of course!
BUT: All enterprise projects – of many different clients – which I have seen, are not that flexible. Enterprise applications do not change every month or year. If there is a project, where you can change your version very easily, Spring might be better than JEE under some circumstances. But in most enterprise projects, you cannot simply upgrade from Spring 2.5 to Spring 3.x or from JEE 5 to JEE 6. I wish this would be possible, but low flexibility and politics rule in large companies with thousands of employees.
Due to the reasons I explained against Spring in the „BUT“ parts, I will choose JEE in most new Enterprise Java projects. Nevertheless, I will sometimes use a Spring libraries, too (such as Spring Batch). Sometimes, I will even have to use Spring (if I need its flexibility or power), but only then I will choose it. Of course, for existing projects, I will continue using the framework that is used already. I would probably not migrate a Spring 2.5 application to JEE, but I would migrate it to Spring 3.x instead!
So, I have described my reasons why I will use JEE in most new Enterprise Java projects. If I have missed something, or if you have got another opinion (probably many guys have), you can bash me in the comments. I appreciate all „non-flame-war“ discussions…
Best regards,
Kai Wähner (Twitter: @KaiWaehner)
One of the greatest wishes of companies is end-to-end visibility in their operational and analytical…
Time flies… I joined Confluent seven years ago when Apache Kafka was mainly used by…
Snowflake is a leading cloud data warehouse and transitions into a data cloud that enables…
The integration between Apache Kafka and Snowflake is often cumbersome. Options include near real-time ingestion…
Snowflake is a leading cloud-native data warehouse. Integration patterns include batch data integration, Zero ETL…
Google announced its Apache Kafka for BigQuery cloud service at its conference Google Cloud Next…
View Comments
This is the answer to many questions. I agree with you!
I agree with everything you said. But spring has a great autentication and authorisation framework (old acergy) integrated. And its help us a lot. JEE has something like that?
Hey Daniel.
Spring Security may be one of the features which is more powerful than the JEE standard. In our last projects we had to implement low-level LDAP or NTLM integration for some reasons. Usually, we use the Atlassian stack (Jira, Confluence, Crowd) whenever possible because IMO Atlassian makes awesome easy-to-use products for a fair price. Crowd is used for Single-Sign On.
Best regards,
Kai Wähner (Twitter: @KaiWaehner)
Thanks for writing this up.
Even though you concluded with JEE, seems like a pretty even fight. I think developer experience will probably sway the vote in most EE environments. Dev. teams are probably even harder to switch then frameworks.
@Danny:
You are absolutely right! The "fight" will not end, because you can realize most applications with both alternatives. I also know developers who prefer Spring. Of course, developer experience is important, too.
Though, the trend goes in the direction of JEE (in my opinion). In a while, there will be much more JEE developers than Spring developers available. One reason is that all guys coming from universities will learn the lightweight standard and there is no reason to learn Spring at the university anymore (contrary to J2EE times, where Enterprise Java was too complex to solve problems quickly).
Best regards,
Kai Wähner (Twitter: @KaiWaehner)
Isn't Oracle the Vendor who controls JEE? Sure they maybe a commitiee but isn't certfication only possible from Oracle?
I would also argue that as SPRING can do what JEE can do, then it comes down to where the most developers are at. And there are more that have learned SPRING than JEE. Agreed that is due to the legacy days of J2EE, but that is the way it is.
Also what about using TomEE?
http://jaxenter.com/tomee-be-small-be-certified-be-tomcat-38434.html
Using SPRING with this you get the best of both worlds no?
Hi,
I think a comparison between JEE and Spring for the sake of comparison has no real value. I support the approach of using the minimum libraries you need for the project as you need them, and not decide in advance to go all-JEE or all-Spring.
You should first start (at least in your mind) with a main() method, and ask yourself what else you need: DB access? REST endpoints? Transactions? Then pick the tools that you think fit best for your specific needs. You may end up deciding that you don't need JEE/Spring, or even a web container at all. For example you can do amazing stuff with Guice.
JEE containers may be a lot better today than J2EE, but that doesn't mean you should use one if you don't get a real benefit from it over the alternatives. As for the specific JSRs, you may or may not use each of them in your project (some JSRs are also supported by Spring), but that too shouldn't necessarily lead to all-JEE architecture.
Personally I agree that the more flexibility you need, the better you choose Spring and other open source libraries. If you stick to JEE, you may need to wait for years to get features that are available today in such libraries.
@Gabriel:
As I have stated at the beginning of the article, I had to choose between JEE and Spring for future projects - I did not say that I wanted to choose :-)
In theory, your suggestion may be possible. Also in some companies, this may be possible.
In practice, best-of-breed is not possible in many large companies. Politics and other keywords such as "technology consolidation", "know-how transfer", and so on prohibit your suggested approach.
I have seen this in several companies - and often it is not a bad idea IMO. My company also does Enterprise Architecture Management. There are so many application silos with different technologies, and the people with know-how already left. :-(
Best regards,
Kai Wähner (Twitter: @KaiWaehner)
@LazyFan:
Well, you could use TomEE and combine Spring with JEE. But why would you do that? IMO, it would only increase complexity. If you want to use Spring, you should use its tc Server (and buy support for this server). If you combine Spring and JEE, you have to buy support for both, as Adam Bien stated some months ago in a blog:
http://www.adam-bien.com/roller/abien/entry/java_ee_6_xor_spring
You may argue that you do not need that support, but in mission-critical systems, this support is necessary.
I am no expert in this TCK certification stuff, but many other vendors made the certification for JEE in the past.
Best regards,
Kai Wähner (Twitter: @KaiWaehner)
Hi Kai! It's not bad to have a bias in this discussion. If view points don't differ then where is the value add in discussion. Seriously, I believe you have a strong JEE bias (you only have the "buts" against the Spring option) and you explain why. Again, that's OK and its the only way I see to add value here.
I do agree to many points you mention. To me its not a matter of features to be honest in the end 'cause features are well sorted in both architectural options. It's also not a question of "heavy weght" or so. In the end (to me) it's a decision where you want to place your framework libs: in the server lib directories or with the WAR/EAR file in WEB-INF/lib. Now what's the consequence: if you have all the stuff in the server lib and you use those APIs directly then
(1) migrating JEE servers will become non-trivial due to the migration and testing efforts associated
(2) therefore not all the clients want to migrate cause they don't see a reason -> result: multiple JEE server versions in IT landscape, multiple local dev env versions due to different Java versions in production, more complex ALM solutions - all in all: more complexity and more heterogeneous landscape
(3) shift of responsibility: in Spring scenario the development or application architecture guys decide what to use und also have the knowledge to fix problems in production. in a JEE case the operations team is in charge of the application framework libs, they typically don't have the knowledge and need vendor support
(4) less flexibility: e.g. you need to talk to procurement guys before you can add a new framework feature of a new server version (licensing costs), or e.g. you need to talk to operations team to upgrade. as with Spring you just compile a new version of your WAR/EAR file and deploy that to a java runtime of your choice
(5) snowball-effect: you need one feature but 'cause the app server you're using (and in JEE you're not the only stakeholder that can decide which server to use!) doesn't have that feature you need to upgrade. Ups, you need to migrate and retest all your application 'cause all the API versions changed!
Now, all in all I think I do have a strong Spring bias. As soon there is a solution to these extensive problems I will change my mind 'cause obviously my live would be much easier if I could just say: we use the JCP "standard" programming model. Unfortunately, this is not the case right now.
Also, I do believe it's not JEE against Spring, it's CDI vs. Spring IoC in particular and its also about like EJB or not. Also, it's a lot about independence of your business applications from the underlying application server runtime. E.g. we use EJB but the business app doen't know 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 apps. And sometimes its better not to use some app server lib dir derived ones ;-)
JEE is moving towards a good direction. More modularity (as a standard) would be desireable to make it more applicable to complex and large IT environments.
Cheers, Niklas