J and I and Me
2010-10-13
  Spring vs. Java EE and Why I Don't Care
Disclaimer: I work for VMware / SpringSource. That means I might be biased - but then again we did not just create Spring. We are also a member of the Java EE 6 Expert Group. The views are my personal view of course.

History


Spring has established itself as a very popular solution for Enterprise Java applications. In particular the advantages of Spring as compared EJB 1.x / 2.x were very obvious and were a major reason for Spring's success.


The Current State


Due to Spring’s early success and adoption, Java EE 5 and Java EE 6 were pushed to greatly simplify the Java EE programming model, increase developer productivity and become much simpler to use than previous versions. The current Java EE 6 solutions are thus just now achieving the ability to compete against Spring's programming model. Developers now are ready to ask the question "Why you would prefer Spring?" Here is my take:



Before we start a flame war and get lost in technical details let me reiterate: Java EE and Spring can have a similar programming model. Spring is more flexible and I would prefer it. But: I don't think your project will fail because of the decision you made concerning this. And: I think a Java EE vs. Spring shoot out will be boring. If you do a side by side comparison you will end up with minor differences such as @Component instead of @Stateless or whether you will need to deploy some additional JARs. While that might be impressive in a demo I don't believe this will convince anyone to use one platform or the other. Certain features of Spring (e.g. the flexibility to use XML or Java based configuration) will probably not be shown as they just cannot be done using Java EE.


Why I don't care


So if a side by side comparison doesn't make a lot of sense - why would I choose Spring? There has to be a clear advantage somewhere to definitely answer this question. A personal note at this point: I am frequently work at a shared office space with some JavaScript and Ruby on Rails guys - I am the only Java guy there (and sometimes I think they pity me). After talking a lot with these other developers, I believe we need a compelling Java story that can live up to their developer experience. If Java EE and Spring are both on a comparable level concerning productivity we need to come up with novel ideas to improve. Looking at Ruby on Rails helps here - the approach is to combine a dynamic language with a powerful framework and a code generator. The next level of productivity is not Java EE vs. Spring. It must be something that can counter the productivity of Ruby on Rails. I believe this is:



So if you look at productivity the comparision should not be "Java EE vs. Spring" but rather "Groovy / Grails vs. Spring Roo vs. Ruby on Rails". Better productivity is not gained on the level of the framework or the programming model any more.


Asking the Wrong Question


The other reason why I think "Spring vs. Java EE" is the wrong question is: Both models on their own do not solve the challenges I typically see in projects. Let me give you some examples:



So there are a lot of challenges Java EE just has no solution for. A side by side comparison of Spring and Java EE might lure you to believe that JSF + Spring / Java EE + database is all you will ever need. Look at your projects and decide for yourself if that is true. It certainly contradicts my experience.


Sum Up


To cut a long story short:



...and a last thing


So you have read this blog post to the end. That is great - thanks a lot! Please don't start a religious battle now. Instead code something or do something fun. Enjoy!

Labels: , ,

  10:42
Bookmark and Share
Comments:
Nice post, thanks for sharing.
 
Maybe Ruby needs clouds because its threads are poor. (i am not sure)
 
Nice post showing the real significant problems of Java in its current state - I experience the same. Inside the java world all is shiny, because noone looks around.

There arent any real webframeworks which allow one to deliver like the ruby developers do - exceptions are playframework, spring roo and partly grails (having pure java frameworks allows more "developer reusability" and has a better learning curve).

Requirements for fast developing have changed, but java has not at all in this regard. It is still in is "enterprise world" - what ever this may be.
 
I think the big problem with the adoption of grails/RoR is the crazyness of managers using "standard-compliant" software.

If you show them how productive these dynamic frameworks are they seem to really like it but in the end they are frightened to use it. Maybe they think they will be "vendor-locked" or will find no developers for "these" frameworks. I dont know.
 
Well done, Eberhard!

Among other things, your post depicts why Spring is still interesting for Java EE architects, and the Spring framework is often a valid option (compared to Java EE 5/6).

Thanks.
StefanZ
 
I tried RoR like framework and i am back in Java. The generated code was good for prototyping but not for production. You will save 20 minutes when creating GUI in RoR but you will lost days and days when maintaining the application in next years.
RoR is good for HelloWorlds, but I am sorry, you wont run investment bank on it.
 
Thanks for sharing! I really experienced the same.
 
Why nobody mentions JRuby???? JRuby on Rails just rocks. Why copying something that already exists (Grails > Rails). Rails is so much better and with version 3 Rails made a huge step.

JRuby on Rails has all the advantages Java offers (Hotspot optimization, Threads, ...) and the huge and great Ruby/Rails community behind it. You don't have to fight Ruby/Rails, you have to embrace and just use it.

And you are right, nobody cares about JEE/Spring.
 
Nice post. However, I think it's a bit disingenuous to put Roo on the same footing as Grails. Roo is a far, far, less mature technology (I doubt there's a single production site of any significance that uses Roo). The only reason I can see why someone would choose Roo is because their manager won't let them use Groovy.
 
Hi Samir,
thanks for your feedback! You are right, I did not mention JRuby explicitly. But as I said Groovy / Grails might be the better option than Ruby / Rails as it "is more adapted to the JVM and has better integration with Java". I think the integration in the JVM and Java is important if you want to run a different language on the JVM. So for example you will need to translate between the two type systems.
Best regards,
Eberhard
 
I have done several projects with Rails on JRuby in the last years and it turns out, that you should give it a try instead of only focussing on Grails/Groovy.
I prefer to stay on top of the ongoing productivity with Rails 3 (decoupled ORMs etc.).
You mentioned the NoSQl stuff. With Rails you can choose between SQL and NoSQL ORMs which handle persistence absolutely transparent to the user.
Java developers that don't need to focus on enterprisy stuff and who are focussing on web projects should take a look around and try even one of groovy/grails or JRuby/Rails. It will blow their mind away.
BTW, I don't use Rails generators for other than getting the right files in the right directory ;)

@Anonymouns: If you switched back from Rails to Java and think that the generators are only able to do "hello world" stuff: Take a deep breath and try it again, without generators and ask your self, what you really want to get when using rails.

@eberhard: I'm looking forward to W-JAX conference in November and would love to discuss your thoughts togheter with Adam Bien and Stefan Tilkov. Maybe we can come out with some interesting stuff for the attendees.
 
Certain features of Spring (e.g. the flexibility to use XML or Java based configuration) will probably not be shown as they just cannot be done using Java EE.

This is wrong, it's possible through CDI extension and a SEAM-XML is available for this purpose (http://docs.jboss.org/seam/3/xml-config/latest/reference/en-US/html_single/). I am currently using CDI in a SE environment.
 
Java EE "just now" user friendly? Java EE 5 has been out for many years. Please think again.

And using Spring inside a war to push updates of Spring into production, when you are not allowed to update the core platform on which your app depends is just wrong...
 
Good post, but I think it should also mention that there are multiple vendors for JavaEE but only one - to my knowledge - for Spring.

JavaEE 6 is still early, but so far we already have GlassFish 3 (3.0.1 out, 3.1 almost). JBoss 6 is in M5. IBM and Caucho have also announced they are making good progress, and so has Oracle's WebLogic Server.

Standards create choice, which is good for consumers/customers.
 
Java EE main point is to provide compatbility between different provider runtimes based on standards. Also, in Java EE 6, it provides profiles, such as Java EE Web Profile. For example, SIwpas (http://code.google.com/p/siwpas/) implements Java EE 6 Web Profile concepts, it is easy to use and based on Tomcat 7. Others are also working on implementing Web Profiles.
 
How about mentioning in the introduction that you work for SpringSource?? For a while there I thought this was an unbiased comparison/description when clearly it is not.
 
Personally, I have never thought frameworks that rely on code generation a lot would be the answer. Otherwise we would be doing model driven development by now (and surely some people are doing it, but it's not widespread and success stories seem to be in niche areas mainly).

I have more belief in JVM languages that let you raise the level of abstraction to achieve more productivity (personally I use Scala). These languages can already use the plethora of Java libraries out there, but to bring productivity up, they just need time to grow new libraries more suited to the mixed functional/OO programming model.
 
Oh, but I totally agree with the main point of the post: Spring vs. Java EE is a boring question. In a recent project, we used Wicket + Spring + Spring Security + Spring Remoting + JPA (Hibernate) + JTA + Camel, where the entity manager, transaction manager, message queues and data sources came from the Java EE environment, but everything else was glued together via Spring beans. In that way, Spring mixes with Java EE quite nicely.
 
@Anonymous: I added a disclaimer. Note, however, that we did not just create Spring. We are also a member of the Java EE 6 Expert Group.
 
Dieser Kommentar wurde vom Autor entfernt.
 
@Gurkan @pelegri There are two Java EE 6 certified application servers: Glassfish and TMAX JEUS 7, see http://java.sun.com/javaee/overview/compatibility.js . Concerning the portability there is an interesting blog post here: http://techblog.bozho.net/?p=213 . I would actually argue that an application that uses Spring is more portable as it can run on Tomcat, Java EE servers and in the Cloud.
 
@Johan Concerning Java EE 5 and 6: The second sentence in the blog post actually states that these two release did a great step in the right direction.

Concerning pushing out Spring updates as part of the application: This is one of the differences that is caused by the fact that Spring is part of the application while Java EE is part of the application server. I don't really think this is an issues. You will probably use other frameworks as well so you need some way to manage and approve the versions of the frameworks anyway. But you are right in pointing out that this is a difference.
 
@Franck Seam is not part of the Java EE standard - it is just another framework. Also the version 3.0 you mention is currently in beta. However, there are ways to do the configuration in XML that I forgot to mention (sorry) such as the EJB XML Deployment Descriptors. However, the syntax is actually not that easy and usually they are not used nowadays. Before the annotation based configuration tools like XDoclet were used to generate them...
 
@sb looking forward to meet you at WJAX and have a nice discussion!
 
Thanks for sharing this.

I think that the combination of Netbeans integration, EJB3.1, CDI, JSF2/Facelets w/ PrimeFaces or OtherFaces has become so lean that we don't need Grails & co anymore. When you abandon advanced layering in EE 6, what you do in grails, you develop at the same speed/productivity.

(I don't know yet if it's the same in Spring, I admit)
 
JRuby is indeed a very nice option when using the Rails framework. It may even be the only chance for Rails to get adopted in larger enterprises.

But IMHO while Java integration works in JRuby it just doesn't feel natural and has a weird syntax. The documentation isn't very good and just focuses on Swing (which is nice for demonstrations but not needed in web development).

That's why I chose a combination of Java and Groovy for development. Groovy just integrates seamless with Java and Grails combines the power of Java with the productivity and fun of Rails.
 
@Jihed: Thanks for your feedback! Actually Spring still integrates a lot of technologies. In particular it run happily on Java EE 6. Jürgen Höller, the lead engineer, will probably write a blog post about that.
 
Seam is not part of the Java EE standard - it is just another framework
CDI extension is part of the Java EE standard and SEAM-XML is such an implementation. Do you get the nuance?
 
Hi Franck,
thanks for your feedback. What I tried to say is: CDI defines an SPI to create custom extensions. This SPI is standardized. The extension, however, are not. So for example they would need to be deployed to the app server - just like a framework like Spring.
 
JEE vs. Spring is indeed a boring question. But so is Rails vs. Roo vs. Grails. Basically they are all old-school server-side markup generators and POST-Redirect-GET ping-pong players.
 
Forget Ruby on Rails, Spring Roo or Grails, there is already a java framework with high-productivity : Play! Framework.

Have a look at it, and you won't have anymore to bother about Spring vs JEE for Web development
 
Honestly, this is the first coherent thing I read about the comparisons between Spring and JavaEE.
 
Tto me Spring came about because of weakness in JavaEE. Essentually an Enterprise "fork" occurred.

With joining together on JavaEE6 things are moving in the right direction.

I sometimes wish that innovations in the Spring realm made it into the JavaEE world more often or even occurred directly in Java EE world and not splitting people into two camps.
 
Excellent article!. You forgot to mention SpringSource investments about OSGI. If you are using OSGI, SpringSource’s stuff gives you a lot of advantages. And relating to the issue of “Spring updates as part of the application” is not a big issue if you are using OSGI.
 
That was a good one! Thanks for sharing your thoughts. Even though it is playing a bit to much in the hands of VMware and SpringSource. (but you already mentioned it in your disclaimer)
 
Idunno ...

You constantly say the next big thing will be something for the Java programmer. I see an analogy here: lots of companies deciding to move all of their applications and infrastructure services to either Java or .Net.

Any programmer with a few years of experience can tell that no company will ever be able to build an infrastructure which is pure Java or pure .Net. Usually it's a mixture, plus PHP, plus RoR, plus some legacy apps where most of the logic is in the database, plus an older SAP still using ABAP, plus some VB6, maybe some ancient native code CGIs etc.

IMO/IME, it's not the organizations which are able to move most of their infrastructure to just one technology that are highly successful, but the ones which are able to properly manage complexity.

IMO, the same holds for software development. The best possible solution is usually not one which uses the best possible Java frameworks and libraries, but the one which uses the best possible frameworks and libraries regardless of technology, and manages to properly integrate them. You cannot create a browser UI that's more responsive in server-side Java than you can with some trivial Javascript, and you cannot perform some batch processing in a database with the same speed abd low mem footprint in Java as you can using SQL. Maintaining business logic in SQL is stupid and a maintenance nightmare, accessing relational databases from javascript, although possible, gives up all the nice speedup you gain from moving most of the logic to the client. Therefore, the best solution is IMO in most cases a more or less even mixture of several technologies, with proper management and maintenance.

With the advent of HTML5, and the ever-increasing importance of web apps in the enterprise space, I think the next big thing won't be some Java framework or library, but a Javascript library. IMO, the best thing Spring could do for Java programmers isn't to further maintain and develop things like spring web flow or spring mvc, but to create nice and easy to use spring integrations with next generation Javascript frameworks like sproutcore, ext, smartclient, rialto or qooxdoo. IMO, better integration with such frameworks is what's going to give server-based frameworks the edge, not better old-style server-side business logic support.
 
most important reason would be familiarity if you are familiar with Spring than why do you bother to go J2EE same is true for someone who is already using J2EE6.

Thanks
Ldap Authentication Example using Spring Security
 
Kommentar veröffentlichen

<< Home
J for Java | I for Internet, iMac, iPod and iPad | Me for me

ARCHIVES
Juni 2005 / Juli 2005 / August 2005 / September 2005 / Oktober 2005 / November 2005 / Dezember 2005 / Januar 2006 / Februar 2006 / März 2006 / April 2006 / Mai 2006 / Juni 2006 / Juli 2006 / August 2006 / September 2006 / Oktober 2006 / November 2006 / Dezember 2006 / Januar 2007 / Februar 2007 / März 2007 / April 2007 / Mai 2007 / Juni 2007 / Juli 2007 / August 2007 / September 2007 / Oktober 2007 / November 2007 / Dezember 2007 / Januar 2008 / April 2008 / Mai 2008 / Juni 2008 / August 2008 / September 2008 / November 2008 / Januar 2009 / Februar 2009 / März 2009 / April 2009 / Mai 2009 / Juni 2009 / Juli 2009 / August 2009 / September 2009 / Oktober 2009 / November 2009 / Dezember 2009 / Januar 2010 / Februar 2010 / März 2010 / April 2010 / Mai 2010 / Juli 2010 / August 2010 / Oktober 2010 / Januar 2011 / Februar 2011 / März 2011 / April 2011 / Mai 2011 / Juni 2011 / August 2011 / September 2011 / November 2011 / Februar 2012 / April 2012 / Mai 2012 / April 2013 / Mai 2013 / Juni 2013 / Januar 2015 / Juli 2015 / Februar 2016 /

Links

Twitter
Google +
Slideshare
Prezi
XING
LinkedIn
Das Spring Buch


Feeds

Feedburner


Impressum
Betreiber und Kontakt:
Eberhard Wolff
Leobschützer Strasse 22
13125 Berlin
E-Mail-Adresse: eberhard.wolff@gmail.com

Verantwortlich für journalistisch-redaktionelle Inhalte:
Eberhard Wolff