It is always entertaining to read articles with a “Java EE vs Spring” topic, as the discussions are normally very emotional and quite funny. So I always told my self: “Don’t write another Java EE vs Spring article” – BUT: Here it is.
The reason is that I read an article in the current issue of German Java Magazin (4.2011 ). In the series “EnterpriseTales” the authors give this reommendation:
Generally we recommend to use the standard in new projects, if there are no reasons to not chose the standard.
With standard the authors mean “Java EE 6”, as the article is about a comparison of Java EE 6’s CDI and Spring .
For me one question arised: Is Java EE 6 really the standard for Java Enterprise development? What is a standard? So I asked Wikipedia:
A technical standard is an established norm or requirement about technical systems . It is usually a formal document that establishes uniform engineering or technical criteria, methods, processes and practices. In contrast, a custom, convention , company product, corporate standard, etc. which becomes generally accepted and dominant is often called a de facto standard .
Two really interesting points: A standard is an established norm and something generally accepted and dominant is a de facto standard.
I am developing Java since 1996 and since 1999 also with the Java Enterprise Edition. Some parts of Java EE I would call “established” based on my experience. For example the Java Servlet Specification . Servlets have basically not changed since 1999 and I cannot remember that we had major migration efforts in the last decade. The WAR archive, web.xml and the major interfaces have been stable and the servlet specification has carefully improved over the years. (e.g. servlet filters) Almost all major web frameworks are based on the Servlet API and I would say that servlets are one of the reasons why Java has been a big success on the server side. (compare it to CGI and you know what I mean) Also the support by major vendors was very good. There are lots of servlet conatiners/application servers out there, which are stable and used in thousands of production environments (Tomcat , Jetty, JBoss , Weblogic, WebSphere , …).
Let’s get back to Java EE – which is more than servlets. There are many parts of this “standard” where my experience was not so positive. Let’s look at the Enterprise JavaBeans standard, which in my point of view is a desaster. I used EJB 1.0 in 1999 as the promise was to have a standard for Enterprise component development with container managed security, transaction, persistence etc. The standard didn’t last for long. With EJB 1.1. you had to do a migration of your existing code. The same with EJB 2.0 which was a whole new redesign of the standard. And now EJB 3.x which has nothing to do with former EJB standards (except the naming) and copied the POJO model from established frameworks like Spring, but with limited support for dependency injection in other parts of Java EE. This is the reason why Java EE 6 looked at JBoss Seam and implemented CDI. If you look at JPA (part of EJB), it looks like a limited Hibernate clone – nothing to do with former entity bean standards (by the way: Do you remember the JDO standard? Where is it today?) What about application server support? It took years to have EJB3 support in major application servers (like WebSphere) and I don’t know application server in production that fully support Java EE 6. What about investments in this standard? Trainings for the developers, tons of lines of code around EJB 1.x-2.x, …
For me EJB is an example that Java EE has nothing to do with a standard – because it is not “established”. For years the Java EE standard is runnning after the innovation of defacto standards – like Hibernate or EclipseLink . Or Spring, or GWT, or …
The new standard is often just a bad copy of the original. Look at JPA: A political API that is reduced to a minimum set of functionality. Was JPA 1.0 useable? I don’t think so – can you really use a O/R mapper without a second level cache? Why should I use JPA in favor to Hibernate which is stable for years, has much more functionality and I can use it in any application server/servlet engine? Answer: There is no reason.
JSF is another example. Build to provide software vendors to sell component libraries and tools, it never worked as expected (I did a JSF 1.0 project and still feel the pain, when I remember it). Facelets tried to overcome the issues and finally it was taken over as the standard. Now you have a “1.0 framework” and we are already years in the “2.0 world”. Look at frameworks like GWT or Vaadin and you know what I mean. If you use AJAX and JSF – please be careful with the memory – JSF was not designed for such use cases.
CDI (Java EE 6) vs Spring is a similar discussion for me. Spring has a stable IOC implementation for more than 5 years. The investment in Spring (training, etc.) is still worth the money and I cannot remember major migrations because Spring never fundamentally changed it’s design. Each release is a consequent and innovative improvement (annotation, AspectJ, …) – this is the reason why I would call Spring a defacto standard. CDI/Java EE 6 may have a similar (or in some parts even better) feature set, but this doesn’t make it a standard for me, especially if I look in the past. Who guarantees that Java EE 7 will not be the next migration?
So let’s get back to the initial statement of the Java Magazin article:
Generally we recommend to use the standard in new projects, if there are no reasons to not chose the standard.
I can only support the statement, but Java EE 6 is not a standard! Because it is not established! Parts of it are established for sure (like Servlet API), but other parts like EJB 3.x and CDI will have to prove there stability in the future. Therefore I would say that you should carefully evaluate what is a (defacto) standard you should chose. Spring or Hibernate are defacto standards in my point of view, as they are used in thousands of projects for years. Adam Bien (a popular speaker and freelancer working with Java EE 6) says in the same Java Magazin (page 52 – translated by the author of this blog):
CDI is not ready yet.
CDI is missing critical features like transactions or asynchronous processing which are available in EJB 3.1. You could reimplement them in CDI, but a minimalistic solution would be a combination of EJB 3.1 with CDI in Java EE 6 (se for example http://www.oracle.com/technetwork/issue-archive/2011/11-jan/o11java-195110.htm …”
“…
CDI could take off with Java EE 7. It could provide the EJB 3.1 exclusive features to the public.
…”
Ok – Java EE 7. The JSR says: final release in Q3 2012. As we know from Java 7 this means: “maybe end of 2013 with major application server supporting it in 2015”. So I will use the defacto standards like Spring, Hibernate or GWT and will observe the official standard. If it someday will be stable and established I will consider switching to it – but I could imagine that Spring and Co. will have moved again two steps ahead…
Was this post helpful?
More articles
fromMirko Novakovic
21.2.2014 Your job at codecentric?
Jobs
Agile Developer und Consultant (w/d/m)
Alle Standorte
Gemeinsam bessere Projekte umsetzen.
Wir helfen deinem Unternehmen.
Du stehst vor einer großen IT-Herausforderung? Wir sorgen für eine maßgeschneiderte Unterstützung. Informiere dich jetzt.
Hilf uns, noch besser zu werden.
Wir sind immer auf der Suche nach neuen Talenten. Auch für dich ist die passende Stelle dabei.
Blog author
Mirko Novakovic
Do you still have questions? Just send me a message.
Do you still have questions? Just send me a message.