Why is Java EE 6 better than Spring ?

Guest Author

Java EE 6 was released href="https://blogs.oracle.com/arungupta/entry/java_ee_6_is_now">over
2 years ago and now there are href="http://www.oracle.com/technetwork/java/javaee/overview/compatibility-jsp-136984.html">14
compliant application servers. In all my talks around the
world, a question that is frequently asked is

Why should I use Java EE 6 instead
of Spring ?

There are already several blogs covering that topic:
  • href="http://bill.burkecentral.com/2012/03/13/java-ee-wins-over-spring/">Java
    EE wins over Spring by Bill Burke

  • href="http://www.kai-waehner.de/blog/2011/11/21/why-i-will-use-java-ee-jee-and-not-j2ee-instead-of-spring-in-new-enterprise-java-projects-in-2012/">Why
    will I use Java EE instead of Spring in new Enterprise Java
    projects in 2012 ? by Kai Waehner (href="http://www.theserverside.com/news/thread.tss?thread_id=63784">more
    discussion on TSS)

  • Spring to Java EE migration (Part href="http://www.oracle.com/technetwork/articles/java/springtojavaee-522240.html">1
    and href="http://www.oracle.com/technetwork/articles/java/springtojavaee2-1414289.html">2,
    3 and 4 coming as well) by David Heffelfinger

  • href="http://ocpsoft.org/java/spring-to-java-ee-a-migration-guide-cdi-jsf-jpa-jta-ejb/">Spring
    to Java EE - A Migration Experience by Lincoln Baxter

  • Migrating
    Spring to Java EE 6
    by Bert Ertman and Paul Bakker at
  • href="http://www.theserverside.com/discussions/thread.tss?thread_id=61023">Moving
    from Spring to Java EE 6 - The Age of Frameworks is Over
    at TSS
  • href="http://www.slideshare.net/kelapure/java-e-evsspringshootout">Java
    EE vs Spring Shootout by Rohit Kelapure and Reza Rehman at
    JavaOne 2011
  • href="http://www.devchronicles.com/2011/11/javaee6-and-ewoks.html">Java
    EE 6 and the Ewoks by Murat Yener
  • href="https://blogs.oracle.com/arungupta/entry/qa_8_java_ee_6">Definite
    excuse to avoid Spring forever - Bert Ertman and Arun

I will try to share my perspective in this blog.

First of all, I'd like to start with a note:

Thank you Spring framework for
filling the interim gap and providing functionality that is now
included in the mainstream Java EE 6 application servers. The Java
EE platform has evolved over the years learning from frameworks
like Spring and provides all the functionality to build an
enterprise application. Thank you very much Spring framework!

While Spring was revolutionary in its time and is still very popular
and quite main stream in the same way Struts was circa 2003, it
really is last generation's framework - some people are even calling
it href="http://bill.burkecentral.com/2012/03/13/java-ee-wins-over-spring/">legacy.
However my theory is "code is king". So my approach is to build/take
a simple Hello World CRUD application in Java EE 6 and Spring and
compare the deployable artifacts.

I started looking at the official tutorial href="http://static.springsource.org/docs/Spring-MVC-step-by-step/">Developing
a Spring Framework MVC Application Step-by-Step but it is
using the older version 2.5. I wasn't able to find any updated
version in the current 3.1 release. Next, I downloaded Spring Tool
Suite and thought that would provide some template samples to get
started. A least a quick search did not show any handy tutorials -
either video or text-based. So I searched and found a link to their
SVN repository at href="src.springframework.org/svn/spring-samples/">src.springframework.org/svn/spring-samples/.

I tried the "mvc-basic" sample and the generated WAR file was 4.43

While it was named a "basic" sample it seemed to come with 19
different libraries bundled but it was what I could find:


And it is not even using any database!

The app deployed fine on GlassFish 3.1.2 but the "@Controller
Example" link did not work as it was missing the context root.

With a bit of tweaking I could deploy the application and assume
that the account got created because no error was displayed in the
browser or server log.

Next I generated the WAR for "mvc-ajax" and the 5.1 MB WAR had 20
JARs (1 removed, 2 added):


2 more JARs for just doing Ajax.

Anyway, deploying this application gave the following error:

Caused by: java.lang.NoSuchMethodError: org.codehaus.jackson.map.SerializationConfig.<init>(Lorg/codehaus/jackson/map/ClassIntrospector;Lorg/codehaus/jackson/map/AnnotationIntrospector;Lorg/codehaus/jackson/map/introspect/VisibilityChecker;Lorg/codehaus/jackson/map/jsontype/SubtypeResolver;)V
    at org.springframework.samples.mvc.ajax.json.ConversionServiceAwareObjectMapper.<init>(ConversionServiceAwareObjectMapper.java:20)
    at org.springframework.samples.mvc.ajax.json.JacksonConversionServiceConfigurer.postProcessAfterInitialization(JacksonConversionServiceConfigurer.java:40)
    at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.applyBeanPostProcessorsAfterInitialization(AbstractAutowireCapableBeanFactory.java:407)

Seems like some incorrect repos in the "pom.xml".

Next one is "mvc-showcase" and the 6.49 MB WAR now has 28 JARs as
shown below:


The app at least deployed and showed results this time. But still no

Next I tried building "jpetstore" and got the error:

[ERROR] Failed to execute goal on project org.springframework.samples.jpetstore:
Could not resolve dependencies for project org.springframework.samples:
org.springframework.samples.jpetstore:war:1.0.0-SNAPSHOT: Failed to collect
dependencies for [commons-fileupload:commons-fileupload:jar:1.2.1 (compile),
org.apache.struts:com.springsource.org.apache.struts:jar:1.2.9 (compile),
javax.xml.rpc:com.springsource.javax.xml.rpc:jar:1.1.0 (compile),
org.apache.commons:com.springsource.org.apache.commons.dbcp:jar:1.2.2.osgi (compile),
commons-io:commons-io:jar:1.3.2 (compile), hsqldb:hsqldb:jar: (compile),
org.apache.tiles:tiles-core:jar:2.2.0 (compile), org.apache.tiles:tiles-jsp:jar:2.2.0 (compile),
org.tuckey:urlrewritefilter:jar:3.1.0 (compile), org.springframework:spring-webmvc:jar:
3.0.0.BUILD-SNAPSHOT (compile), org.springframework:spring-orm:jar:3.0.0.BUILD-SNAPSHOT (compile),
org.springframework:spring-context-support:jar:3.0.0.BUILD-SNAPSHOT (compile),
org.springframework.webflow:spring-js:jar:2.0.7.RELEASE (compile), org.apache.ibatis:
com.springsource.com.ibatis:jar: (runtime), com.caucho:com.springsource.com.
caucho:jar:3.2.1 (compile), org.apache.axis:com.springsource.org.apache.axis:jar:1.4.0 (compile),
javax.wsdl:com.springsource.javax.wsdl:jar:1.6.1 (compile), javax.servlet:jstl:jar:1.2 (runtime),
org.aspectj:aspectjweaver:jar:1.6.5 (compile), javax.servlet:servlet-api:jar:2.5 (provided),
javax.servlet.jsp:jsp-api:jar:2.1 (provided), junit:junit:jar:4.6 (test)]: Failed to read
artifact descriptor for org.springframework:spring-webmvc:jar:3.0.0.BUILD-SNAPSHOT: Could
not transfer artifact org.springframework:spring-webmvc:pom:3.0.0.BUILD-SNAPSHOT from/to
JBoss repository (http://repository.jboss.com/maven2): Access denied to: http://

It appears the sample is broken - maybe I was pulling from the wrong
repository - would be great if someone were to point me at a good
target to use here.

With a 50% hit on samples in this repository, I started searching
through numerous blogs, most of which have either outdated
information (using XML-heavy Spring 2.5), some piece of
configuration (which is a typical "feature" of Spring) is missing,
or too much complexity in the sample. I finally found href="http://krams915.blogspot.com/2011/01/spring-mvc-3-hibernate-annotations.html">this
blog that worked like a charm. This blog creates a trivial
Spring MVC 3 application using Hibernate and MySQL. This application
performs CRUD operations on a single table in a database using
typical Spring technologies.  I downloaded the sample code from
the blog, deployed it on GlassFish 3.1.2 and could CRUD the "person"
entity. The source code for this application can be href="http://spring-mvc-hibernate-annotations-integration-tutorial.googlecode.com/files/spring-hibernate-mysql.zip">downloaded
here. More details on the application statistics below.

And then I built a similar CRUD application in Java EE 6 using
NetBeans wizards in a href="http://netbeans.org/kb/docs/web/jsf20-crud.html">couple of
minutes. The source code for the application can be href="//cdn.app.compendium.com/uploads/user/e7c690e8-6ff9-102a-ac6d-e4aebca50425/f4a5b21d-66fa-4885-92bf-c4e81c06d916/File/a25b37b7cc50143350ffeb4f4e66a908/javaee_mysql_maven.zip">downloaded
here and the href="//cdn.app.compendium.com/uploads/user/e7c690e8-6ff9-102a-ac6d-e4aebca50425/f4a5b21d-66fa-4885-92bf-c4e81c06d916/File/a8df0548417786f31cb15ce83fcc4a8e/javaee_mysql_1_0_snapshot.war">WAR

The Spring Source Tool Suite may also offer similar wizard-driven
capabilities but this blog focus primarily on comparing the
runtimes. The lack of STS tutorials was slightly disappointing as
well. NetBeans however has tons of href="http://netbeans.org/kb/">text-based and href="http://netbeans.org/community/media.html">video tutorials
and tons of material even by the href="http://netbeans.org/community/">community. One more bit
on the download size of tools bundle ...

NetBeans 7.1.1 "All" is 211 MB (which includes GlassFish and Tomcat)

Spring Tool Suite  2.9.0 is 347 MB (~ 65% bigger)

This blog is not about the tooling comparison so back to the Java EE
6 version of the application ....

In order to run the Java EE version on GlassFish, copy the href="http://dev.mysql.com/downloads/connector/j/">MySQL
Connector/J to glassfish3/glassfish/domains/domain1/lib/ext
directory and create a JDBC connection pool and JDBC resource as:
./bin/asadmin create-jdbc-connection-pool --datasourceclassname \\
com.mysql.jdbc.jdbc2.optional.MysqlDataSource --restype \\
javax.sql.DataSource --property \\
portNumber=3306:user=mysql:password=mysql:databaseName=mydatabase \\
./bin/asadmin create-jdbc-resource --connectionpoolid myConnectionPool jdbc/myDataSource

I generated WARs for the two projects and the table below highlights
some differences between them:

cellpadding="2" cellspacing="2">

Java EE 6


WAR File Size

0.021030 MB

10.87 MB (~516x)

Number of files


53 (> 2.5x)

Bundled libraries



Total size of


12.1 MB

XML files



LoC in XML files

50 (11 + 15 + 24)129 (27 + 46 + 16 +
11 + 19) (~ 2.5x)

Total .properties




spring.properties, log4j.properties

Cold Deploy

5,339 ms

11,724 ms

Second Deploy

481 ms

6,261 ms

Third Deploy

528 ms

5,484 ms

Fourth Deploy

484 ms

5,576 ms

Runtime memory

~73 MB

~101 MB

Some points worth highlighting from the table ...
  • 516x WAR file, 10x deployment
    - With 12.1 MB of libraries (for a very basic
    application) bundled in your application, the WAR file size and
    the deployment time will naturally go higher. The WAR file for
    Spring-based application is 516x bigger and the deployment time
    is double during the first deployment and ~ 10x during
    subsequent deployments. The Java EE 6 application is fully
    portable and will run on any Java EE 6 compliant application

  • 36 libraries in the WAR
    - There are href="http://www.oracle.com/technetwork/java/javaee/overview/compatibility-jsp-136984.html">14
    EE 6 compliant application servers today. Each of those
    servers provide all the functionality like transactions,
    dependency injection, security, persistence, etc typically
    required of an enterprise or web application. There is no need
    to bundle 36 libraries worth 12.1 MB for a trivial CRUD
    application. These 14 compliant application servers provide all
    the functionality baked in.

    Now you can also deploy these libraries in the container but
    then you don't get the "portability" offered by Spring in that
    case. Does your typical Spring deployment actually do that ?

  • 3x LoC in XML - The
    number of XML files is about 1.6x and the LoC is ~ 2.5x. So much
    XML seems circa 2003 when the Java language had no annotations.
    The XML files can be further reduced, e.g. faces-config.xml can
    be replaced without providing i18n, but I just want to compare
    stock applications.
  • Memory usage - Both
    the applications were deployed on default GlassFish 3.1.2
    installation and any additional memory consumed as part of
    deployment/access was attributed to the application. This is by
    no means scientific but at least provides an initial ballpark.
    This area definitely needs more investigation.

Another table that compares typical Java EE 6 compliant
application servers and the custom-stack created for a Spring
application ...

cellpadding="2" cellspacing="2">

Java EE 6


Web Container

53 MB
(tcServer 2.6.3 Developer Edition)


12 MB
(Spring Security 3.1.0)


6.3 MB
(Hibernate 4.1.0, required)

Dependency Injection

5.3 MB

Web Services

796 KB
(Spring WS 2.0.4)


3.4 MB
(RabbitMQ Server 2.7.1)

936 KB (Java client 936)


1.3 MB
(Spring OSGi 1.2.1)

and WebLogic (starting at 33 MB)

83.3 MB

There are differentiating factors on both the stacks. But most of
the functionality like security, persistence, and dependency
injection is baked in a Java EE 6 compliant application server but
needs to be individually managed and patched for a Spring
application. This very quickly leads to a "stack explosion". The
Java EE 6 servers are tested extensively on a variety of platforms
in different combinations whereas a Spring application developer is
responsible for testing with different JDKs, Operating Systems,
Versions, Patches, etc. Oracle

has both the leading OSS lightweight server with GlassFish and the
leading enterprise Java server with WebLogic Server, both Java EE 6
and both with lightweight deployment options.

The Web Container offered as part of a Java EE 6 application server
not only deploys your enterprise Java applications but also provide
operational management, diagnostics, and mission-critical
capabilities required by your applications.

The Java EE 6 platform also introduced the Web Profile which is a
subset of the specifications from the entire platform. It is
targeted at developers of modern web applications offering a
reasonably complete stack, composed of standard APIs, and is capable
out-of-the-box of addressing the needs of a large class of Web
applications. As your applications grow, the stack can grow to the
full Java EE 6 platform. The GlassFish Server Web Profile starting
at 33MB (smaller than just the non-standard tcServer) provides most
of the functionality typically required by a web application.
WebLogic provides battle-tested functionality for a high throughput,
low latency, and enterprise grade web application. No individual
managing or patching, all tested and commercially supported for you!

Note that VMWare does have a server, tcServer, but it is
non-standard and not even certified to the level of the standard Web
Profile most customers expect these days. Customers who choose this
risk proprietary lock-in since VMWare does not seem to want to
formally certify with either Java EE 6 Enterprise Platform or with
Java EE 6 Web Profile but of course it would be great if they were
to join the community and help their customers reduce the risk of
deploying on VMWare software.

Some more points to help you decide choose between Java EE 6 and
Spring ...

  • Freedom to choose container
    - There are href="http://www.oracle.com/technetwork/java/javaee/overview/compatibility-jsp-136984.html">14
    EE 6 compliant application servers today, with a variety
    of open source and commercial offerings. A Java EE 6 application
    can be deployed on any of those containers. So if you deployed
    your application on GlassFish today and would like to scale up
    with your demands then you can deploy the same application to
    WebLogic. And because of the portability of a Java EE 6
    application, you can even take it a different vendor altogether.

    Spring requires a runtime which could be any of these app
    servers as well. But why use Spring when all the required
    functionality is already baked into the application server
    itself ?

    Spring also has a different definition of portability where they
    claim to bundle all the libraries in the WAR file and move to
    any application server. But we saw earlier how bloated that
    archive could be.

    The equivalent features in Spring runtime offerings (mainly
    tcServer) are not all open source, not as mature, and often
    require manual assembly. 

  • Vendor choice - The
    Java EE 6 platform is created using the Java Community Process
    where all the big players like Oracle, IBM, RedHat, and Apache
    are conritbuting to make the platform successful. Each
    application server provides the basic Java EE 6 platform
    compliance and has its own competitive offerings. This allows
    you to choose an application server for deploying your Java EE 6
    applications. If you are not happy with the support or feature
    of one vendor then you can move your application to a different
    vendor because of the portability promise offered by the

    Spring is a set of products from a single company, one price
    book, one support organization, one sustaining organization, one
    sales organization, etc. If any of those cause a customer
    headache, where do you go ? Java EE, backed by multiple vendors,
    is a safer bet for those that are risk averse.

  • Production support -
    With Spring, typically you need to get support from two vendors
    - VMWare and the container provider. With Java EE 6, all of this
    is typically provided by one vendor. For example, Oracle offers
    commercial support from systems, operating systems, JDK,
    application server, and applications on top of them. VMWare
    certainly offers complete production support but do you really
    want to put all your eggs in one basket ?

    Do you really use tcServer ? ;-)
  • Maintainability - With
    Spring, you are likely building your own distribution with
    multiple JAR files, integrating, patching, versioning, etc of
    all those components. Spring's claim is that multiple JAR files
    allow you to go à la carte and pick the latest versions of
    different components. But who is responsible for testing whether
    all these versions work together ?

    Yep, you got it, its YOU!

    If something does not work, who patches and maintains the JARs ?
    Of course, you!

    Commercial support for such a configuration ? On your own!

    The Java EE application servers manage all of this for you and
    provide a well-tested and commercially supported bundle.

While it is always good to realize that there is something new and
improved that updates and replaces older frameworks like Spring, the
good news is not only does a Java EE 6 container offer what is
described here, most also will let you deploy and run your Spring
applications on them while you go through an upgrade to a more
modern architecture. End result, you get the best of both worlds -
keeping your legacy investment but moving to a more agile,
lightweight world of Java EE 6.

A message to the Spring lovers ...

The complexity in J2EE 1.2, 1.3, and 1.4 led to the genesis of
Spring but that was in 2004. This is 2012 and the name has changed
to "Java EE 6" :-) There are tons of improvements in the Java EE
platform to make it easy-to-use and powerful. Some examples:
  • Adding @Stateless on a POJO makes it an EJB
  • EJBs can be packaged in a WAR with no special packaging or
    deployment descriptors
  • "web.xml" and "faces-config.xml" are optional in most of the
    common cases
  • Typesafe dependency injection is now part of the Java EE
  • Add @Path on a POJO allows you to publish it as a RESTful
  • EJBs can be used as backing beans for Facelets-driven JSF
    pages providing full MVC
  • Java EE 6 WARs are known to be kilobytes in size and deployed
    in milliseconds

  • Tons of other simplifications in the platform and application

So if you moved away from J2EE to Spring many years ago and have not
looked at Java EE 6 (which has been out since Dec 2009) then you
should definitely try it out. Just be at least aware of what other
alternatives are available instead of restricting yourself to one
stack. Here are some workshops and screencasts worth trying:
  • href="http://www.youtube.com/watch?feature=player_embedded&v=UBNaiVWwAZw">screencast
    #37 shows how to build an end-to-end application using

  • href="https://blogs.oracle.com/arungupta/entry/web_app_development_using_java">screencast
    #36 builds the same application using Eclipse
  • href="//cdn.app.compendium.com/uploads/user/e7c690e8-6ff9-102a-ac6d-e4aebca50425/f4a5b21d-66fa-4885-92bf-c4e81c06d916/File/a69da0a353108f4f2ce7553cec93ee66/javaee6_hol_feb2012.pdf">javaee-lab-feb2012.pdf
    is a 3-4 hours self-paced hands-on workshop that guides you to
    build a comprehensive Java EE 6 application using NetBeans

Each city generally has a "spring cleanup" program every year. It
allows you to clean up the mess from your house. For your software
projects, you don't need to wait for an annual event, just get
started and reduce the technical debt now! Move away from your
legacy Spring-based applications to a lighter and more modern
approach of building enterprise Java applications using Java EE 6.

Watch this beautiful presentation that explains how to migrate from
Spring -> Java EE 6:

value="http://www.parleys.com/dist/share/parleysshare.swf">name="allowFullScreen" value="true">value="direct">name="flashVars" value="sv=true&pageId=2749">src="http://www.parleys.com/dist/share/parleysshare.swf"
flashvars="sv=true&pageId=2749" allowfullscreen="true"
bgcolor="#222222" height="780" width="480">

List of files in the Java EE 6 project:


List of files in the Spring 3.x project:


So, are you excited about Java EE 6 ? Want to get started now ? Here
are some resources:
  • href="http://www.oracle.com/technetwork/java/javaee/downloads/index.html">Java
    EE 6 SDK (including runtime, samples, tutorials etc)
  • GlassFish
    Server Open Source Edition 3.1.2

  • href="http://www.oracle.com/technetwork/java/javaee/downloads/ogs-3-1-1-downloads-439803.html?ssSourceSiteId=ocomen">Oracle
    GlassFish Server 3.1.2 (Commercial)
  • href="https://blogs.oracle.com/arungupta/entry/java_ee_6_using_weblogic">Java
    EE 6 using WebLogic 12c and NetBeans (Video)
  • href="https://blogs.oracle.com/arungupta/entry/screencast_37_java_ee_6">Java
    EE 6 with NetBeans and GlassFish (Video)
  • href="https://blogs.oracle.com/arungupta/entry/web_app_development_using_java">Java
    EE with Eclipse and GlassFish (Video)

Join the discussion

Comments ( 86 )
  • Werner Keil Thursday, March 22, 2012


    Thanks, nice overview and examples. Not that I'm such a big fan of java.util.logging, but just seeing both commons-logging-1.1.1.jar and slf4j*.jar in the classpath makes the myriads of different dependencies obvious just for something as trivial and seemingly basic as logging.

    Jürgen Höller himself admitted, not referring to any of those in particular, managing different versions of the same dependency was a tricky thing, and it seems, the various people involved either in the Spring sub-projects or others used by the Spring portfolio each had their own ideas what to use..?;-/

    It is a great pity, Spring Social won't get worthy equivalent or successors in the Java Standard landscape, as those who value Software Patents over true Open Standards have won to suppress it for now, but then Java EE is Version 6 now. And Spring Framework Version 3. Spring Social is only around Version 1, and some of its closests competitors like Seam Social already Version 3. A sign of maturity, but again, the reasons why it was not accepted to get contributed into JSR 357 had little to do with maturity of the standard, Sun already got Social-Site only stopped by the Oracle takeover.



  • Hal Thursday, March 22, 2012

    Think that this would be fairer if you included the 16 person years it takes to actually get a commercial J2EE server up and running correctly.

  • Sharat Thursday, March 22, 2012

    Amazingly insightful. Fantastic blog entry. Thanks for taking time to post this to the Java community.

  • guest Thursday, March 22, 2012

    Something wrong to use eclipse/sts wizards to create project samples just like you did with netbeans?

  • Oliver Gierke Thursday, March 22, 2012

    Hi Arun,

    kinda longish post so my reply might get a bit longer as well but I'd like to comment on a few of the issues you've pointed out here. Not to convince you to change your opinion but to maybe cast a slightly different light on some aspects you mention. Disclaimer: working for SpringSource.

    1. Up-to-dateness of sample projects - point taken, definitely an argument and we're working on at least the samples we publish ourselves to provide easy to start with projects to let people judge technical capabilities of the competing platforms.

    2. Number of JARs - what is your point here? First, no one has to collect them by hand anymore. At least I'd consider everyone still doing so as rather unprofessional as this is a more or less solved problem through Ivy or Maven. In fact, the reason Spring is split up into a variety of modules is that one can pick and choose the stuff one needs. If we shipped Spring as one monolithic JAR (which we did back in the days) I would just see your blog post contain the claim: "Look how monolithic and fat Spring is. You have to deploy all this code just for dependency injection". So either way you have something to bash :).

    I guess your general point is that you don't see no reason why would one want to deploy the programming platform along side ones application, right? It seems so obvious as you apparently save 10MB (c'mon, we have TB harddisks and push data over GB networks) as of your example. Actually I don't want to compare package sizes but rather give you some tactical arguments why it might make sense to bundle the JARs with your application. If you really want to push libs off your WAR you can still use a shared library folder of your container. Yes, you will have to make sure they work together correctly but read on to see why I think this is a good thing and you'll probably need to test that anyway.

    3. Decouple programming model from infrastructure - to get the latest and greatest features of JavaEE 6 you need to run a JavaEE 6 application server of a vendor of choice. Assuming you have existing legacy infrastructure you've got to get your operations team onboard, justify upgrade costs etc. Even if you start from scratch right now you wil inevitably run into this situation for the next JavaEE version. Exactly the opposite with Spring: you can even get JPA 2 (a JavaEE standard btw.) running in a Tomcat 5 if you have to (probably for reasons that are out of the development team's influence). That's quite portable I'd argue. Yes, you of course have to upgrade Spring as well but that has usually been a drop in replacement and doesn't have to involve anyone except the development team in case politics allow. Either way platform upgrades have to be well controlled and organized but I'd argue the flexibility point is on the Spring side here.

    4. The myth of portability - it's 2012 and I wonder it's still around. Have you ever tried to port a non-trivial JPA 2 application from JPA provider A to B (which you will effectively do if you switch application servers)? I have spend days on glitches in the implementations, special traits of each of them, some even not implementing the spec correctly but backing out on "the TCK doesn't bark". I am not even saying this is a real issue, as most apps will never need to migrate. You still don't even have the problem if your app ships it's persistence provider. Ironically it might even get more portable due to that fact.

    5. Upgradeability - assume we find a bug in spec implementation X which affects our application. It might even be solved in a more recent version, what do we do? Right, we ship the newer version of the implementation alongside our app and off goes consistency. Or are you seriously suggesting never ever upgrading you persistence provider library in 3 or 4 years? And if you did so, it's probably a "big bang" thing as the entire platform is upgraded. I am just generally arguing that there's value in making sure you get the right set of dependencies in your runtime classpath in the first place, run tests against those etc. Just because you don't need to worry about additional libs for the hello world scenario it doesn't mean you won't have to for a non-trivial app. You will have to anyway.

    6. Freedom to choose a container - just to get this right: Spring apps happily run in all JavaEE containers and can leverage infrastructure as needed. In fact it runs on many many more platforms than JavaEE 6 does as it can run (and leverage JavaEE 6 APIs) on legacy systems as well as new cloud based deployment platforms like Cloudfoundry and Heroku. JavaEE is simply no option there.

    7. XML configuration - welcome to 2012 - you can run a Spring web application *without a single line of XML*. As of 3.1 not even a persistence.xml file is required (unlike the standard actually requires). Full support for Servlet 3 (hey yet another JavaEE standard) programatic web configuration etc. So if you compare the minimum JavaEE setup to a Spring one please be fair not to add stuff that you could add but don't have to (in terms of configuration files).

    8. Future proof - Spring has a *lot* to offer outside the scope of what JavaEE actually provides. A standard solves yesterdays problems by definition (or even the ones from two years ago ;). This is nothing I really criticize, it's just as it is. We don't even have to consider more advanced scenarios like the NoSQL space but rather basic stuff: clean JDBC access, support for environments, declarative pluggable caching, a rich ecosystem of products (e.g. batch and integration) which you can either completely ignore if you don't need them or pick and choose from and get an extremely consistent programming model. With JavaEE you usually have to hope no to suddenly face a requirement that's not covered by the standard. Of course you can go library again then but off goes your consistency and "it's all in the container" approach.

    I already replied similar things [0] to the blog posts you mentioned and on stackoverflow [1] (which the interested reader might wanna take a look at as well to judge). I am looking forward to the discussion.



    [0] http://javacodegeeks.com/2012/03/why-i-will-use-java-ee-instead-of.html#comment-460547151

    [1] http://stackoverflow.com/questions/2822812/spring-3-0-vs-j2ee-6-0/2823389#2823389

  • Armando Flores Friday, March 23, 2012

    Great post Arun.

    For those who wants a JEE 6 "birds eye view" can check this excelent article from "Java Tech Journal":



  • James Bayer Friday, March 23, 2012

    Disclaimer - I am a VMware employee and former WebLogic Server Product Manager at Oracle. I know Arun personally and he is my friend. The views expressed below are mine own and do not necessarily represent the views of my employer.


    I'm really surprised to see you trolling Spring like this. I realize that in your job as a Java EE evangelist that you want to advocate for products and frameworks that you are paid to advocate for, but I don't see the point in misrepresenting many of the attributes that people like about the Spring Framework. I find it hard to believe that you actually believe this blog is a balanced and objective analysis. I must say that I never hear the question why should I use Java EE 6 versus Spring, most developers has made up their mind and most have chosen Spring (2/3 of developers according to Evans Data http://www.vmware.com/company/news/releases/vmw-spring-momentum-3-14-12.html). I guess if you're paid to travel around the world telling people not to use the most popular Java framework that you need to come up with reasons. From what I can tell the people screaming the hardest not to use Spring are mostly authors employed by vendors that have a strong interest to lock-in their customers to full Java EE server instead of a framework that lets them (but not requires them!) to run on a Servlet or Java SE container. In your publications list I see authors employed by vendors selling JBoss, Resin, WebSphere, Glassfish and WebLogic Server. There have been lots of people that have a different point of view on this topic. What I really don't understand as why someone promoting the Java ecosystem as their primary job wants to so obviously dissuade users from making up their own minds with an objective analysis of trade-offs, especially when it does not have to be a mutually exclusive choice and Spring is part of the Java community. You know that many other people (in fact the vast majority of Java developers) do not share your view, yet you do not provide a single link to present an alternative perspective. Are Spring advocates not part of the Java community in your view?

    I find it very strange that you try and attach a "l"-word attribute to Spring when the major app server vendors have not even been shipping full Java EE 6 releases until so recently that almost no customers have the latest versions of WebLogic, WebSphere or JBoss installed. Java EE 6 came out in December of 2009 which is 2+ years old, WebLogic Server 12c only started supporting a Java EE 6 compliant server 3 months ago! WebSphere 8.0 was summer 2011 and JBoss EAP 6 is not even yet generally available. You are advocating to use a framework with implementations that are so new that almost no customers of the major application servers have a compliant server in production. Java EE 6 is not even available in the Oracle Public Cloud yet, so if Oracle can't even upgrade their containers that fast how can you expect all the customers to be up-to-date? Spring 3.1, which had a lot of features for a minor release, started shipping in the Fall of 2011, almost 2 years after Java EE 6. Plus as you probably are aware, it supports Java SE 5 and above, so customers are not required to be on the bleeding edge to use it.

    You had some trouble finding a tutorial, and I am happy to help you with that since that should be very easy. First go to http://www.springsource.org/ and you should click the big button that says "Get Started". The next page has the links for both tutorials and sample code. The tutorials page http://www.springsource.org/tutorials has both video and written tutorials. If you want to create an MVC style application, there is one called "Green Beans: Getting Started With Spring MVC" by Colin Sampaleanu. http://blog.springsource.com/2011/01/04/green-beans-getting-started-with-spring-mvc/ Someone helpfully published a maven archetype in the comments and with only two maven commands you can run the sample with Apache Tomcat, no separate application server installation is required! http://code.google.com/p/flaveur/source/browse/trunk/m2/baremvc/README If you also wanted to use persistence, you could consider a video like Spring Data JPA by Oliver Gierke http://www.youtube.com/watch?v=Yg2gCpBCkZw

    The listing of jar files in the application is not complete if you don't list all the jar files inside Glassfish or WebLogic Server that implement Java EE 6. The comparable Apache Tomcat list of jars is obviously much smaller. You know that an application is a container + framework code + application code and you should represent the entire accurate picture.

    As for jpetstore, that's not really an updated Spring example as you can see by the Spring version being only a SNAPSHOT before 3.0.0 was released. It should probably be removed from the list of samples. The error you saw in maven is from an issue with a JBoss repository. When I removed the JBoss repository at the bottom of the pom.xml file and updated the Spring version from a SNAPSHOT to RELEASE then my maven build worked fine. If you want to use a sample that is often highlighted by Spring advocates, then you could look at Spring Travel, but it is only based on Spring 3.0 and not yet taking advantage of all of the Spring 3.1 capabilities. https://src.springframework.org/svn/spring-samples/travel/

    Your comparison tables are also Apples and Oranges. You can simply put Tomcat or Jetty in that comparison table and tc Server Standard edition is under 15MB http://repo.vmware.com/pub/rhel5/vfabric/5/x86_64/. If you include tc Server, then you should use the Standard Edition recommended for production at 15MB as the Developer Edition includes Spring Insight, which would require including JRockit and JRockit Mission Control in the Java EE 6 column. I suppose it doesn't help your case to point out that the production version of WebLogic Server 12c has a 1 Gigabyte generic zip installer and that the smaller developer versions are not suitable or supported in production. I think you are also well aware of the fact that you could run Spring apps on embedded Tomcat 7 which is just a few megs. I simply amazed that you think tc Server is proprietary when it is based on Apache Tomcat, the reference implementation of the Servlet Specification, which is part of Java EE! Why would you want to mislead people like that? You know as well as I do that there are lots of WebLogic Server customers that are stuck using weblogic.ejb... packages in their code from previous versions of the specification. The only thing even close to that might be Tomcat valves, but over 1/2 of all Java applications use Tomcat these days http://blog.newrelic.com/2012/01/10/infographic-oss-java-wins-in-the-cloud-era/, which is free and open source, so it's not locking anyone in.

    VMware provides commercial support for both Tomcat and Spring as open source products and customers are not left on their own to manage jars. VMware also provides commercial products like tc Server, which is Apache Tomcat with some additional management and configuration capabilities and other open source derived products in the vFabric family that represent the way most modern applications are built. VMware customers are free to use open source with or without commercial support or they can choose a commercial product derived from open source, the choice is theirs.

    While Java EE 6 was finalized over 2 years ago, Spring has moved on to simplify and provide solutions to lots of other problem domains with Spring Data applied to NoSQL (MongoDB, GemFire, Riak, Redis, Neo4j) and Big Data (Hadoop) http://www.springsource.org/spring-data. Spring Social http://www.springsource.org/spring-social has already been available providing solutions to integrate with Twitter, Facebook, LinkedIn, TripIt and Github while JSR 357 is just getting started http://jcp.org/en/jsr/detail?id=357. Developers want solutions to these problems now, not when RedHat, Oracle and IBM get around to it.

    People may not realize that you and I are friends and I'm happy to see you are passionate about your job, but I can't let you misrepresent the facts without setting the record straight. I don't understand the Java EE vendor mentality that encourages deriding Spring when so many developers use it effectively and like it. Go ahead and cheer for your team, but to misrepresent what you see as the other team's case is disingenuous. I personally find it very deflating to the Java community as a whole when you, Bill Burke and others write trolling articles. Hopefully only the vendors are paying attention in these artificial and made-up scuffles while productive developers are actually getting work done.


    James Bayer


  • James Bayer Friday, March 23, 2012

    Arun, I wrote a long response to represent a more balanced and objective view than I felt you portrayed, but it kept getting marked as spam by TypePad AntiSpam. Please see my comments here: http://www.iamjambay.com/2012/03/arun-gupta-java-ee-6-and-spring.html




  • Markus Eisele Friday, March 23, 2012

    Dear Arun,

    I have written up some thoughts about this. And I would love to see this "ancient fight" going back to a valuable discussion for everybody.




  • alex Friday, March 23, 2012

    You guys must be desperate if you have to resort to Karl Rove's tactics, but anyway, let me try to be more serious.

    The fundamental question I have is Why would someone want to move from Spring to JEE?

    It can't be because of many-times-discussed-and-dismissed-by-the-community argument of JEE being a standard simply because its not. Its just another specification which can only become a standard if it gets a wide community adoption. Remember standards evolve naturally.

    It can't be portability. Anyone who ever tried to port WebLogic app to WAS to JBoss etc. knows that its neither simple nor trivial. And even if it is somehow simpler with JEE how often do enterprises move from one platform to another?

    It certainly can't be the maturity of the programming model. JEE is a new guy in town which literally took its lead and pressure form Spring while presenting it as innovation, so from my angel its a bigger risk which I might not be willing to take unless there is some quantifiable benefit and we know all what that is in the world of business. . .

    So what is it? What is the trigger that should make me start thinking about moving to JEE? FUD, really? Is that the best thing that Oracle and RedHat innovation machine has to offer? Articles like this are misleading and hardly objective since you showing example of the application that does not represent even a 20% of the scope of the real Enterprise application of today unless. . . you limit the scope of Enterprise application to only what is defined by JEE. And even if you do/did its quite irrelevant for one simple reason. No CIO or CTO ever cared about Spring or JEE. They would drop them both in a second if some other programming model or framework came along that would help them cut cost (development, maintenance, operations etc.). That's it. That is the only thing that matters to the business. Can JEE do that? Are there any success stories, case studies?

    But if you agree that the requirements of today's enterprise go far beyond what JEE covers than what is your proposal on how to handle such requirements? Use JEE with Spring or other frameworks on top? Sure its doable but why? Why would I want to move from unified programming model that can address 90% of my requirement has more than enough experts available world wide, has a been successfully around for over 10 years etc., has many publicly available case studies to a Christmas tree programming model that would require me to restructure my IT organization and take on the greater risk? Is there any ROI?

    May be you can shad some light but for now I'll stick with Spring since it keeps my investors happy and my developers asleep at night.

  • guest Friday, March 23, 2012

    It's naive to think that JEE is lightweight compared to Spring.

  • guest Friday, March 23, 2012

    LOL Arun, do you consider amount of Java EE compliant servers as ADVANTAGE over Spring? Are you kiddin me? You can run Spring on pretty much everything you can imagine ...

  • Reza Rahman Friday, March 23, 2012

    Good job Arun! I think what you have is a good round-up of how Spring (vis-a-vis) Java EE looks like from the perspective of someone just starting up a project and not having much baggage with either technology.

    This touches upon an article series/talk I am putting together on "Java EE Myths and Reality" covering such topics as Java EE upgradability/backward compatibility, portability, innovation, ecosystem vs. strictly Java EE features (via CDI, JSF, Seam, CODI, DeltaSpike, etc), modern Java EE application/server footprint, speed, installation, configuration, Java EE testability, JCP openness and so on.

    Gavin had a good post on some of this a little bit ago that's worth looking at I think: http://planet.jboss.org/post/you_should_upgrade_to_java_ee_6.

  • MisoV Friday, March 23, 2012

    Here's the thing. We all know that developers weren't particularly happy about the old J2EE, so Spring saved the day. People are using Spring ever since. It is pretty easy to find Spring specialist with 5+ years of Spring experience. It's pretty easy to start new Spring project since you did plenty of those before.

    The question is then; WHY should you care about Java EE 6? Yea, it's prepacked nicer than Spring. But you know that's the matter of pasting few lines to maven pom.xml. Does it offer you something that Spring does NOT have? Why should you throw away few years of experience just to switch to something similar?

    I'd really want to hear, what Java EE 6 has that Spring doesn't. Try me.

  • guest Friday, March 23, 2012

    Ironic comments. Spring fanboys and employees trying to take the high road when they have been trolling for years. Funny the can dish it out but cannot take it.

  • Satish Friday, March 23, 2012

    3 years from the time JEE6 spec came out to an application server becomes available and 2 more years before my enterprise considers to adopt it. Seriously, 5 years to use your shiny new APIs. No thanks!

  • Reza Rahman Friday, March 23, 2012

    Typical of SpringSource employees to try to bad mouth anyone that disagrees with them. Of all the people Arun references only *three* are employees of vendors. Lincoln and Bill are employees of JBoss, yes. Rohit works for IBM and co-presented with me, but entirely on his own time.

    Here is the profile of the rest:

    1. Kai Waehner - Consultant

    2. David Heffelfinger - Consultant

    3. Bert Ertman - Consultant

    4. Paul Bakker - Consultant

    5. Cameron McKenzie - Editor in Chief of TSS

    6. Murat Yener - Consultant

    And this is not counting many other passionate Java EE advocates like Antonio, Adam Bien, Werner, etc that have never earned a dime from a Java EE vendor.

    I started writing/speaking well-before I joined Caucho, was never a Caucho employee, currently do not work and Caucho projects and certainly wasn't when I did the presentation.

    I guess it's easier to try to demonize and dismiss others than to face up to the fact that you are dealing with a true grass-roots movement that doesn't agree with you...

  • guest Saturday, March 24, 2012

    Thanks for the statement, Reza.

    Rohit works for the same IBM, having turned down proposals not part of EE7, but at least somewhat related to it for Social Media (JSR 357) the same week it sold those 750 Software Patents to Facebook! We all know, IBM also does a lot of honest Open Source work, e.g. at Eclipse, but that has left a very bad mark on them at least inside the JCP and related to Java Standards like Java EE.

    While having worked with BEA once including projects that went into Portlet or JCR standards, the only way Individual Members like Adam, myself or others might get a dime by any of those vendors is at conferences or similar meetings. And speaking for myself only, I got such invitations over the years from several vendors, SpringSource and Oracle alike, so I can consider myself pretty neutral and unbiased on that;-)

  • Chris Stier Sunday, March 25, 2012

    I would like to see a comparison of JEE6 and Spring Roo. I've been playing with Roo lately and am very impressed with it.

  • nasyuwd Sunday, March 25, 2012

    Perhaps we can all take a deep breath.

    It is important that Java EE and Spring to work together. Remember, Java EE is a set of specifications, and Spring can "implement" these specifications if they wish to. Java EE is not a product.

    (please take another deep breath again...)

    I see a risk in this "war", and I do hope friendship between some of the people in Java EE and Spring, whom we all look up to as role models, remains unaffected.

    More than ever, we need cooperation, collaboration, peace and friendship amongst people, instead of "enhancing" fragmentation/split.

  • Naveed Sunday, March 25, 2012

    "Spring also has a different definition of portability where they claim to bundle all the libraries in the WAR file and move to any application server. But we saw earlier how bloated that archive could be."

    A few days ago I was trying to deploy a JSF application on GlassFish and I was totally not able to deploy that because the issue was my application was using JSF 1.2 while GlassFish 3.1 was conflicting with those jars and even researching a lot I was never able to deploy that application on GlassFish.

    I am in this field since last 6 years and my experience says that its best to be bundle the required jars in the war instead of depending on the server

  • Terence Monday, March 26, 2012

    As a Java EE developer and someone how uses Java EE with and without Spring, I can only think that Arun's article was written for him by a marketing person with an obvious agenda. Seriously, number of bundled libraries? or their MB size? The article was researched/constructed so poorly I'm suprised the spring responders were so restrained.

    I use Spring when I need functionality not available in Java EE, however this occurs a lot. With a combination of legacy systems precluding current versions of Java EE, and some application server vendors slow to adopt (yes I'm looking at you Oracle (Weblogic Server)), Spring is often the only solution.

    A good article would be a comparison between Spring and Java EE6 on how to implement a sample application properly, so that those people who can choose have a good understanding of how each is done.

  • Chris Stier Monday, March 26, 2012

    Actually to correct my previous post... I think a comparison of sts/roo/vFabric vs Netbeans/JEE6/glassfish would be great. I've been developing with Netbeans/Glassfish for the last 3 years and love how fast I can crank out an application with it. Roo seems to be just as quick. I like the idea of being able to create a project from the Roo shell without having to rely on an IDE. However, I'm not sure if it's enough to win me away from Netbeans/Glassfish/JEE6. It's just so easy to use.

  • guest Monday, March 26, 2012

    I agree with nasyuwd.

    Can't we all just get along?

  • giancarlo Monday, March 26, 2012

    I've had experiences with JEE6 containers not following their config files to use the jars included in the war file(Glassfish and Weblogic). It's a real headache and time sink. These experiences lead me to believe that portability between containers tend to not be straight forward.

    Nothing against JEE6 or for Spring.

  • guest Monday, March 26, 2012

    Arun, SpringSource,

    If have been a ebs pl/sql programmer for 15 years; I really like my pay check.

    Java EE 6 looks like a good entry point for me. I am reviewing the Spring MVC 3 application using Hibernate and MySQL at present.

    Satish - "No thanks!" funny.

    JB - You left Oracle, hard for you to be objective I would ASSume.

    From my perch it looks like minds were made up on this topic before the post.

    Arun - Thank you.


  • guest Monday, March 26, 2012

    Arun, Spring Source,

    Java EE 6 looks like a good $$$ entry point for me.

    I am reviewing the Spring application at present; Spring is now a T.B.D. green bar Spring Source.

    Satish - funny.

    From my perch it looks like minds were made up on this topic before the post.

    Arun - Thank you; btw I would take the middle seat and get home a day early anytime.


  • guest Tuesday, March 27, 2012

    Nice article.

    This should be made into a movie titled "Arun Gugpta vs The spring zombies".

  • Arun Gupta Tuesday, March 27, 2012

    Olivier, James, et al

    Its interesting that this blog is called trolling where as that was quite prevalent in the early days of Spring (even now so). I think forgotten are those days when Rod Johnson and crew was trashing J2EE everywhere in the world and made a living/company out of it. Even to date, Spring boys talk about the J2EE platform as if its still 1.2/3/4. I agree the earlier versions of the Java EE platform had some pain points and I, along with several others, definitely felt them. But Java EE 6 has simplified enterprise Java application development significantly and provides an excellent alternative now.

    I did see some tutorials but they were more like Spring commercials instead of educating on how to build a Spring application. The comments in the youtube videos also expressed similar sentiments. There have been complaints in Spring forums about the lack of Spring 3 tutorials as well (http://forum.springsource.org/showthread.php?84684-Getting-started-with-Spring-3-Web-MVC-Setting-everything-up). Spring community is much more active in producing those tutorials but several of them were using 2.5 which I wanted to avoid that version because of the XML-hell. I was looking for something rather simple and nothing of that sort was available on the "Getting Started" website.

    Spring philosophy require the developers to provide the list of JAR files (even if in Maven but still exact version, repos etc need to be known) and build a custom stack with each application. Maven is popular, but not a panacea – many pre-existing enterprise projects simply cannot accommodate the methodology/project file structure/layout that maven projects must inherently adhere to in order to get the dependency management benefit. There’s no getting around having more moving parts that are less integrated, tested and validated (compared to EE 6 platform) when it comes to debugging and resolving issues... and you still have to figure out the dependences in the first place in order to get them into a maven repo for someone else to use. Also, lots of commercial vendors also don’t publish public maven repos for their JARs, so any commercial components that are part of your stack are likely getting missed. Lastly, deployment size matters less on disk, and more about time to deploy, re-deploy, undeploy, etc. in iterative development cycles when dealing with larger deployment units.

    Even with that, a version of JAR file changes, now go and test all over again. A bug is fixed in one of the JARS, go test the custom stack again ? And who is going to support that custom stack ? Even if VMWare provide commercial support on a Tomcat distribution, the customers are still tied to VMWare, just one vendor for all of their issues. That is a definite business risk. That is the exact business risk customers avoid by using Java EE. They build their applications using the Java EE APIs and can choose to run their applications on any compliant application servers. Each application server provide their own nuances in terms of monitoring, management, clustering, reliability etc but the Java EE 6 API are fairly complete to build the enterprise java application and provide true portability. If they are not happy with vendor they can always move to another vendor and Java EE enables that choice. Even Gartner (http://www.gartner.com/technology/reprints.do?id=1-17GUO5Z&ct=110928&st=sb) sees Spring as a proprietary framework and Oracle with their Java EE offering as the leader in the magic quadrant.

    Java EE 6 was released 2+ years ago and there are 14 compliant app servers today. I'm surprised about the comment that no customer has the latest version of WebLogic, Websphere, and JBoss installed. This shows the lack of market knowledge. And this is not even including the umpteen number of GlassFish installations that have been growing drastically for the past 2 years. As a matter of fact, GlassFish has seen the biggest growth in its existence ever under Oracle's stewardship. And then there is Caucho and TomEE and Geronimo and other installations as well. And I always hear great reviews about JBoss AS 7 deployments all around the world even though a commercial version is still not available. And if the deployment is happening on a Java EE server, why not leverage the APIs/features of the underlying app server instead of building a custom stack.

    In terms of cloud deployment, you are probably aware of OpenShift and Cloudbees which already provide Java EE 6 PaaS deployments. The good part of having a standard is that these need not be provided only by the big vendors and Cloudbees is a perfect example of that. Oracle Public Cloud needs are driven by the customers and that's what defines the Java EE version there.

    GlassFish has released a minor version every 6-9 months and a major version every 18-24 months. That has been our typical cadence for the past few years. A fully supported commercial edition is released right along with the open source edition. A bugfix is available using the latest nightly or promoted build for open source customers. A good part of our community do that already and help us improve the build quality. Or supported customers can file a bug and generally get a hot patch within days, and a proper patch within a few weeks. Its not a big bang approach waiting for 3-4 years as suggested.

    As Reza pointed out, there are only 3 posts by employees of vendors in my original blog and everybody else is a consultant. I speak worldwide on Java EE 6 and always get great reviews about the simplicity in the platform. I get the most desperate feedback from the attendees who are locked into XML/JAR-hell made possible by Spring. They love the fact that Java EE servers provide majority of the functionality and they can use other frameworks if needed, not the other way around. This make their solution much more simpler as they can focus on the business logic instead of worrying about the plumbing, JAR versions etc. Spring adoption happened prior to Java EE 6 but I see the platform gaining foothold again. That's the reason I see more blogs where developers prefer Java EE over Spring (http://www.kai-waehner.de/blog/2011/11/21/why-i-will-use-java-ee-jee-and-not-j2ee-instead-of-spring-in-new-enterprise-java-projects-in-2012/).

    Yes, there may be a higher number of developers that know Spring but they are all tied to a single framework governed by a single company. In the Java EE land, there is at least the Java Community Process. The process is not perfect but with JCP 2.8 its becoming much more transparent with a higher level of feedback from the community. Anybody with a java.net account can watch/participate in the EG discussions, download interim spec drafts, share their usecases, create JIRA issues, etc. Its in VMWare's benefit to lock-in developers to Spring framework. If VMWare really care about community and no vendor lock-in, they should really start contributing back to the JCP community. A true community effort is bound to be slow but it drives a much broader choice over all.

    FYI, Tomcat has not been the RI of the Servlet specification since 5.5. All that work is done as part of GlassFish for the past many years now. VMWare picked Tomcat, wrapped a bunch of software around it and calls it a standard, really ?

    Spring 3.1 not requiring "persistence.xml" is yet another example where Spring framework is deviating from the standard and locking-in the developers into VMWare's version of JPA. This is because JPA requires a "persistence.xml" to be present as stated in the comment.

    I just stated my position on why I think Java EE 6 is better than Spring. I understand that after years of preaching Java EE at Oracle, you now have to advocate Spring because of that's what you are paid for. However as the Java EE brand ambassador I want to make sure that the community knows my position. We agree to disagree on this and I'm not expecting an agreement :-) Java EE and Spring are not mutually exclusive as you said but it would be rather more amicable if Spring folks stop bashing Java EE as well.

    Spring was born because of the deficiencies in the J2EE 1.2/3/4 platform, Java EE 5/6 evolved and made it really simple to create an enterprise java application, Spring finally caught up after 2 years by getting away from monolithic JAR and XML-hell, who knows what next. Overall, I see the Java community benefiting from these advancements as they are able to develop applications faster in a shorter time frame and I'm really happy about that. I agree that Java EE 6 and Spring are not necessarily mutually exclusive all the time. However I'm surprised that by me listing the benefits of one platform over another framework I'm judged to be not promoting the Java ecosystem. I completely disagree with that comment. Yes, I'm Java EE evangelist, but then on broader sense I do promote Java and have keynoted, blogged, produced videos, done hands-on lab educating/coaching/spread message around broader Java ecosystem. I'll continue to do so in my capacity to foster the ecosystem. And you can always reach out to me if you need help :-)

  • guest Tuesday, March 27, 2012

    This has definitely been an enlightening and entertaining stream of comments!

    Disclaimer: I too am employed by Oracle. Draw whatever conclusions you must from that. I thought Spring was a pain in the arse before I joined Oracle and I still hold that opinion. It just so happens that I am now paid by Oracle *while* sharing that opinion :)

    Let’s agree to one thing up front - both the JCP and SpringSource seek to serve the Java community.

    In addition to attempting to serve the Java Community, SpringSource needs to continue to serve its own interests.

    There is value in developing standards and there is value in breaking away from the standard in the vein of innovation to create something new. Our society definitely rewards individuals who take this approach. Does SpringSource innovate and help advance the Java platform? Absolutely! Innovation helps drive the standards forward and the standard provides a base for innovation. I think we can all assume that neither Java EE nor Spring will die any time soon and that we will never be without defined standards.

    One thing I find interesting in the ‘competition’ between Java EE and Spring is that since the JCP is public, SpringSource is able to view the process and take their own tack on how to implement the JSR’s included in the Java EE spec and do so before the community has finalized a new version of the spec. Rightfully so, larger corporations like IBM and Oracle would not begin working on implementing the spec before it was final. How long is ‘acceptable’ for vendors to start releasing implementations of the new spec, anyway? It is not just the spec that they have to implement - it is implementing the spec in conjunction with value-added features, backwards compatibility and testing cycles. SpringSource has the flexibility to watch the process and deliver their proprietary interpretation of things very soon after an Java EE spec is released without being encumbered by any other agenda or process – all while putting their own spin on how things should be instead of influencing the JCP and the Java EE Standard for the greater good.

    It would be interesting to see the state of affairs with Java in an alternate universe where Rod Johnson worked through the JCP to improve Java instead of inventing Spring. It was clearly an opportunistic move, and it has served him well. However, I believe that Java would be in a better state if we could have kept the focus on improving Java through the JCP.

    As Arun has stated, and what should be common knowledge by now, Java EE 5/6 did a great deal to improve the original problems and perceptions with J2EE. The original reasons for adopting the Spring framework are no longer valid in many cases. For new development EE6 offers a great deal of productivity for developers. Its designed for this and it delivers. Of course – we can all say that we want people to come to their own conclusions (only after we’ve had a chance to influence them). If we agree not to try to influence the decision process then we should take down java.net and springsource.org ASAP.

    Let’s be clear about one thing - there are developers who most definitely do NOT want to use Spring. This is a fact. They have been forced into it and don’t like it. Let’s not try to paint a picture where every developer in the world is dying to use Spring but is held back by an evil dictator making them stay on J2EE 1.3.

    They are tired of working with XML files and struggling with getting things wired correctly. Sure, 3.0 and 3.1 help with less XML required but that doesn’t help someone who is stuck on 2.5 and can’t upgrade. It also doesn’t appease the frustrations they have had dealing with XML which make them want to switch – just like the argument for EJB 3.0 being simple doesn’t alone make people want to switch back from Spring if their reason for adopting it was EJB 1.1 tribulation. This is only one point, and my goal here is not to provide an exhaustive list. This is one example of a point that is driving some Spring developers to look for other options.

    Also, developers in corporate IT shops do not always get a choice of what they can use. They are often directed what to use by the Team Lead or Architect. You could soundly argue that in order to be a Team Lead or Architect in a large(ish) organization that you need a few years of experience – lets say 5-6. This being the case, when these individuals were ‘coming up’ from being an entry-level developer during the time where Spring was gaining momentum and probably wound up going down the Spring path instead of Java EE. They have learned it and used it for years now and they can be very effective with it – we all use the tools we can be most effective with. I feel this is a major reason for much of Spring’s ongoing success.

    One final ‘content’ note - the Oracle Public Cloud is not released, and there is more to test in OPC than the WebLogic implementation. James, you know this – you were here.

    It’s easy to be a Monday Morning Quarterback on this because we can look back and see the path history has taken. To be honest, the point of these discussions seems lost in posturing and personal defense/offense. What’s the point of this, seriously? There is nothing to be gained from this aside from putting on a show for the masses. Both Spring and Java EE have their champions. Neither side is innocent of not making things personal or bashing the other side – both sides do it regularly and often. Pointing out individual incidents of bashing is neither productive nor conducive to a peaceful existence – assuming that’s what we want… :)

  • guest Tuesday, March 27, 2012

    Well said, Arun.

    One could only hope that Spring would align itself to Java EE standard, even just the Web Profile. That would enable them to then position themselves to compete with other application servers, while at the same time enabling portability. Of course, it's never going to be a straight forward "MOVE", but easier at least.

    The other point is about Weblogic adoption. Our team will migrate to the latest version soon. Yes, it's not happening yet, but if we are migrating it (and we are small team), I'm confident in reality people out there are already using it.

    On Oracle. I did have my reservation when Oracle acquired Sun, but now have to admit that under Oracle, Java (and Java EE) flourish.

  • guest Wednesday, March 28, 2012

    Hilarious debate, guys. So please wake up and back to real work.

  • Mikael Gueck Wednesday, March 28, 2012

    From a customer perspective, this argument should be pursued further in the Java EE 7 timeframe.

    To continue with it in the Java EE 6 era is to the discredit of those involved.

  • guest Wednesday, March 28, 2012

    There are not 14 compliant application servers. There are 7 full profile servers (two of them are listed twice under different licensing models). There are 5 web profile servers, which do not implement a full Java EE stack. Of those 5, three of them are duplicates of the 7 full profile servers. So really there are maybe 10 choices, and of those 2 or 3 are open sourced..

  • Reza Rahman Wednesday, March 28, 2012

    Dear anonymous poster from Oracle,

    Thanks for your valuable comments -- it's good to hear from the "mother ship" every now and then :-).

    I see your point but have to disagree with you on the generalization of "both sides are guilty of making things personal". I am afraid I have a very different perspective on that. Since the years ago that this discussion started until this very day, I can honestly say I've made every attempt to keep this about the technology and not about the people (in fact, Caucho has specific policies around this). In almost every instance, that effort has been made close to impossible in large part due to SpringSource employees (it seems from the highest level to the lowest ranks) making no such consideration. Personally, I have had enough. If this carries on, I feel I have no choice but to seek to change this behavior employing whatever mechanism that will work (if any). One thing I will not do is stop saying what I think because I believe the server-side Java community needs this to continue to be a two-way conversation.



  • Jeffrey West Wednesday, March 28, 2012
  • guest Wednesday, March 28, 2012


    "In addition to attempting to serve the Java Community, SpringSource needs to continue to serve its own interests." - And JCP also has to serve IBM, RedHat and Oracle interests too, and please don't pretend it doesn't. It *should* be more transparent then what SpringSource does, but it's not without its flaws. And you can always fork Spring sources on GitHub. Can you do that to Weblogic? As you said "code is king". Also you mention numerous deployments of the open source JavaEE6 servers but the *Enterprise* or *Comercial* servers started to be available only this year. The discussion is not about student or small companies servers. Big enterprises and the like needs comercial grade Servers. Even the Gartner article you mention excludes glassfish (considering only Weblogic from Oracle). Tell me one single medium-to-big company that uses raw Glassfish or JBoss OSS *without Oracle or RedHat paid support*. And all those companies will only *start* to evaluate migrations to JavaEE6 NOW.

  • Jeffrey West Wednesday, March 28, 2012

    First, it's 'Arun' not 'Aron'.

    No one is pretending that the JCP does not serve the interests of IBM, RedHat or Oracle - they, along with many others (incl. Intel, HP, SAP & Google) are members of the JCP Executive Committee: http://jcp.org/en/participation/committee and as such get to 'decide things' by voting. However, there is no single entity that controls the outcome unlike SpringSource and the Spring Framework.

    From the JCP site:

    Each Executive Committee is expected to:

    - Select JSRs for development within the JCP.

    - Approve draft Specifications for Public Review.

    - Give final approval to completed Specifications and their associated RIs and TCKs.

    - Decide appeals of first-level TCK test challenges.

    - Review maintenance revisions and possibly require some to be carried out in a new JSR.

    - Approve transfer of maintenance duties between Members.

    - Provide guidance to the PMO.

    Voting records can also be found at the link above so you can see how often VMWare votes on things (or decided to show up). VMW had a 10% attendance rate and voted on 68% of the ballots. In 2010 they voted on only one ballot and had a 57% attendance rate

  • guest Thursday, March 29, 2012

    Obviously Java EE 6 is a great step forward compared to 5. Especially from the point of view of reducing complexity. Now I have to use Spring but will move to JSF as soon as I have that opportunity. However there is one regrettable thing about JSF - for the presentation layer it has adopted a way obsolete Facelets solution totally missing all the lessons of component-oriented efforts like Wicket, Tapestry, Click and HybridJava. I am not biased for Spring though - the corresponding place in Spring for me reads as an empty placeholder.

  • guest Thursday, March 29, 2012

    @Arun ahh, well reading this discussion I see well proofed what is my experience from the last 20 years in software development so far.

    What Spring does is decoupling the infrastructure from the programming model and this is an unbelievable value.

    I think you might be a good technology evangelist and promoting the new JEE simplicity but what is with your old applications, systems, services etc. and what will be with the new one in let's say 8 years. Spring has a stable infrastructure independent application architecture for over 8 years now and they won't break I will expect.

    Programming against a standard is just a dream you always program against an concrete implementation in real world problems is the reality. Taking the concrete implementation of your framework from App./Web Server to Web/App. Server over the years is invaluable.

  • Magnus Thursday, March 29, 2012

    Essentially, as someone who's both used J2EE/JEE and Spring quite extensively over my 16 years in developing applications for business use, for me it boils down to this.

    tl;dr version:

    Want a pre-tested platform that a vendor guarantees works wonders (vs certain specs)? Go for JEE. You might have issues keeping up with newer specs/better implementations than your JEE server of choice has, and if you like DDD you'll have to live with some workarounds.

    Want to be able to pick and choose and be responsible for your own choices? Go for Spring. You're on your own in testing your stack.


    longer version:

    It depends on the problem domain, your devs, your organisation and a whole other slew of things.

    JEE has come a very long way over the years, I've in fact (almost) forgiven the standards folks for EJB 2.x (XDoclet to the rescue! err) which "forced" me into Spring land to get my job done in a way I could live with (maintenance).

    The JBoss stack, with Seam, Arquillian and JBoss 7 is really nice. I've also tried Glassfish out, worked quite well for the problems I was solving at the time (also worked with other containers, but yeah).

    However, there have been cases where I've wanted to upgrade the API versions contained in my J(2)EE server(s), and found it quite a hassle, or even in some cases borderline impossible. JPA 2.0 -> JPA 2.1 was such a case when JPA 2.1 had features I really wanted for my problem domain at that time, and would've had to wait for.

    As I didn't really feel like waiting for the JEE server(s) to go through TCK, be released and get stabilized - I went with Spring instead (and the newest version of the API along with Hibernate). It turned out quite ok, despite me being responsible for testing my stack. I must've been lucky.

    To me, the deployment model of Spring is better than JEE's since I can choose my own API:s and implementations based on what I know/hear from people I trust work.

    I don't mind testing it is infact so, my automated test suites usually gives me a high enough degree of confidence that I can take a decision (which I could, thanks to Spring's model of pick-and-choose, change with a moderate amount of work to go for EJB 4.0 or whatever).

    Furthermore, I really like DDD. And sadly enough, JEE isn't really helping in working with "real" DDD (like most of the MVC frameworks). Immutable valueobjects? (Yeah I know Hibernate - and probably other imps as well - can handle this, I'm talking about the spec) Design by contract via a constructor, having some fields final? (Nope, you need a no-arg default constructor)

    I don't like getters and setters, I was pretty much screwed before JPA went for field access.

    I'm really looking forward to a JPA spec that handles mapping more along the line of how Jackson maps objects to and from JSON. But when that happens, my app has been shipped ages ago with the stuff I wanted it to contain at that time.

    To other people, I am sure JEE is a superior choice, for other reasons (such as the ones given in this article).

    On a side note, I don't really think Spring is the main competitor of JEE/JBoss/x these days. It's things like Play framework and new JVM languages (with stacks like the one Typesafe has).

  • Robert Friday, March 30, 2012

    >What Spring does is decoupling the infrastructure from the programming model and this is an unbelievable value.

    No, Spring doesn't do that. You still need Tomcat and a JVM to be present.

    A TRUE decoupling would be considering the Virtual Server as the only infrastructure. The deployment unit is then merely a (Linux) executable. This executable contains the JVM, the AS and the war.

    With different intervals, deployments can then be the full thing, only the AS or only the war.

  • John Waterwood Friday, March 30, 2012

    I really like this article. Great job!

    A recurring argument against Java EE in the past had been that it was larger in size and boots slowely. Here the numbers clearly show this is not the case. Java EE 6 implementations can be both smaller in total size and faster.

    Funny that no one argues with the actual numbers. I guess the Spring fans have immediately done their own testing and observed that Spring indeed starts slower. This must be extremely bitter to them, as it was one of the most often used sticks to beat Java EE with. Rod Johnson used the word "heavyweight" so often that at times it resembled a little kid who just learned a new favorite word. But ironies of ironies, now Spring is heavyweight and Java EE lightweight.

    And what do you know? All of a sudden heavyweightness doesn't matter anymore according to the Spring fans, since disks are large enough? Right...

  • S. Hendriks Sunday, April 1, 2012

    After reading this post I am still not conviced I should switch from Spring to Java EE 6. And let me explain why:

    1. Size does not matter. (Do you really think I am worried about the JAR files coming in my WAR?, in fact I believe JAR's belong in there for several reasons)

    2. You did not tell me why I *should* use Java EE. I have not read how Java EE tackles certain problems and how nice it works. If it works nice you got me interested and I might consider switching. (since Spring is still just a tool. If there are better tools I will use them)

    3. This whole blog post reads like a Spring bash post. And bashing does not make a point. It does gain attention though...

    So my question is: What was the purpose of this blog post?

    Btw, are there any easy tutorials on how to do JEE 6? (as you mentioned the lacking of those for Spring, I was wondering if you had better

  • guest Sunday, April 1, 2012

    Where is the nosql support ? The caching layer? OAuth anywhere ? As it stands today, JEE is the perfect solution for 2006 apps.

    Having said that, spring has a lot to improve too, and they won't succeed facing modern web app development if the standard doest help them.

    Honestly the fact you get Grails and Roo in the Spring portfolio is enough reason to consider their ecosystem rather than JEE one...

    Keep trolling JEE guys, and let new NIO architectures take advance (node.js , netty, vert x).

  • Daniel Thursday, April 19, 2012

    Loved the post you mentioned!

    Java EE 6 and the Ewoks by Murat Yener http://www.devchronicles.com/2011/11/javaee6-and-ewoks.html

  • guest Friday, April 27, 2012


    I read the article:-

    First of all "Arun Gupta" is an Oracle employee, not a person who is independent surveyor or runs own company, so I think he wrote this article in a totally biased manner. But I read it as a neutral reader (not favouring JEE6 or Spring).

    So below are my conclusions: -

    All the points mentioned by him are based on the "helloWorld" application not on the basis of "large applications" which sizes in gb's. So if you include some jars having size in max 20-30 mb's it hardly matters.

    This same applies to the deployment time.

    So first-half of the article becomes useless as per above.

    Below are some other points mentioned by him are completely wrong: -

    First comes to the "container"

    As Arun said JEE 6 application can deployed on any server, so does spring but you have to include its some mb's jar which already present in the WAR. So in large application this hardly matters as stated above.

    Comes to "vendor choice"

    If you used "Spring" in your application, you still use the vendor support", like RedHat, IBM or even Oracle.

    The product from a single company is just too invalid point. When Java came in 1995, it is also from the single company i.e. ”Sun Microsystems”.

    Now "production support"

    You don’t need the "production support from the vmware" if you have employees having good "Spring knowledge", and presently they are easily available in the market. You only may have use the "vmware support" if you are using their server.

    Finally comes to "maintainability"

    Ha-ha.. this man must be joking, if he is saying that "spring applications" are hard to maintain. Instead of running spring applications by simply coping them from some SVN, I suggest him to grab a "Spring in Action" and do some real coding with Spring, he will know the difference.

  • guest Friday, June 1, 2012

    really is this what world has come to?? I never knew Sun now Oracle is so desperate ... evolve the standards to meet the market and do not create standard based on set benchmark !!

    JEE6 is an utter disappointment:

    1. HTML5.. no consideration whatsover i.e. I am talking about web-sockets and some interesting stuff like new input types etc.

    2. Nothing on cloud standards? Not even a mention of no SQL APIs?

    3. Rule engines? Seriously what happened to JSR 94 or something?

    4. Multi-tenancy... or is it the resolving class-loader gotchas with Web-profiles?

    Read these as a major disappointments, I realize Sun was a market leader when they started java.. with Oracle.. its all darkness and documenting whats happening on web to bunch of ignorant developers!

    PS:I have attended your session they are good but from the sales point of view. It saddens me when someone writes such article and calls them technology enthusiast!

  • guest Friday, June 22, 2012

    Hello Arun,

    Could you imagine what would be state of Enterprise Java Development on 2012 without the contributions of Companies like SpringSource and JBoss (Hibernate).

    Image Java EE6 with no CDI or JPA?. Probably would be an EJB 2.1.? on steroids!. Really-really an scary proposition. Don't you think?

    Be careful not bashing to hard your sources of innovation.

    On the other hand: On all the the exception issues that you are showing up. I think it is because you are out-of-touch with different tools and mind-sets that yours.

    Question for you: Is JEE 6 leveraging AOP?. I really don't know it. It brings a lot of programming productivity. Indeed.

    Java EE6 better than Spring? No yet*. I don't think so.

    Thank you

    jD @ http://pragmatikroo.blogspot.com/?view=timeslide

    Certainly has improved a lot. Basically assimilating the good stuff innovated from others. Nothing wrong with that.

  • guest Saturday, July 7, 2012

    What I really find amusing is that for Spring fanbois, its a sin to bash Spring but its divine to bash java ee.

    Its like:

    Arun Gupta: preaching Java ee 6 is better than Spring.

    Spring Fanbois Goes: You heretic, you will be crucified upside down and will be fed to the lions alive.

    Spring Fanboi1: Java ee 6 better than Spring? Not yet. I don't think so.

    Spring Fanboi2: Java ee 6 is a disappointment.

    Spring Fanbois: Fanboi1 and fanboi2, get ready for canonization, you will be a living saint, an example to be put into the heavenly pedestal.

  • jD Saturday, July 7, 2012

    @Mr. or Mrs. Anyboi*,

    Do you have anything else than rhetorical points...

    Would you stand on the side watching the others fighting?

    and at the end, would claim that you always sided with the winner.

    Your "strategy" is not new at all. It has been played many time before.

    So, my translucent anyboi* when are you going to show your true colors?

    B. Roogards

    jD @ http://pramgatikroo.blogspot.com

  • guest Sunday, July 8, 2012


    To make it clear, I am siding on the java ee 6 camp (yeah java ee 4 and below sucks and spring was better then). Maybe I sound rhetorical but I don't want to give technical opinion since it would be a waste time repeating again and again what others had written on their tech blogs. Also I like to see java ee and spring fight for it is worth fighting for, and I can see that java ee 6 is winning the fight. Spring started the fight anyway so it should finish what it started or else java ee will do it for them.

    But what I was pointing out earlier is that I am amused that now that the tide of war is turning against Spring, Spring fans are complaining of too much barage of nukes from java ee 6. Its a fight, what do you expect? Trade a punch coming from Spring with a killer smile from java ee?

    Yes fighting in this context is healthy since it will force each side to better equip themselves or else fade to irrelevance. I don't care if each side send spies and copy each others techniques to make themselves better, because that's the point anyway, make each side better. In the end your correct sir, without a competitor like Spring, java ee could become complacent.

    I think its you sir who should show his true color, are you for Spring or Java ee?

    Also just an opinion, SpringSource joined the JCP largely for political reasons and less technical contributions. As far as I know, they've only championed one jsr(jsr 330, correct me if I'm wrong). Guess who lead the CDI spec? Red Hat. And SpringSource didn't even vote for the CDI and didn't gave any reason for that? Why? Politics. Again just my opinion.

    So there goes your beloved SpringSource, your source of innovation.

  • jD Sunday, July 8, 2012

    Yeah... These are much-much better punches... I am sorry, I mean points.

    Ok. You asked for my true colors ? True color one: Google "pragmatikroo.blogspot.com" and true color two: Google "Spring Roo Jose Delgado*"

    These two lists should answer your question. Did I ?

    Bottom line: Spring Framework should be credited that saved the Java Enterprise market for the Java community. The incarnations of EJB 1.0 to EJB 2.1 were so bad -I am not criticizing here. I am stating well accepted facts for everybody here- that almost destroy the market. If weren't for the Spring framework probably you and I would be coding Ruby of something else at this time.

    The very first company using ioc and di in industrial level for Java Enterprise perspective was Spring. Period. This is a historical fact.

    I have tremendous respect for JBoss almost same level as Spring. I am glad the JCP listens to them otherwise probably we would be in EJB with steroids era.

    Now, I don't know why Java-Enterprise-Establishment (JEE just a naming coincidence) is so mad with Spring. Spring was right on target from the beginning on what was the successful implementation for Java Enterprise paradigm. JBoss should be credited for convincing JEE on use it. Finally.

    I would have to overwrite myself here. I claim that Spring Framework is a source of innovation AND saved the enterprise market for the Java community.

    I hope JEE -now under new administration- go after the real competitor if feeling so cocky. This is where the revenue is located instead of trying to cannibalize a "distant" ally.

    Going after Spring would be like the tale of the scorpion and the frog.


    Think about that...

    B. Roogards

    jD @ http://pragmatikroo.blogspot.com

    *A picture will be retrieved with the list. I am not that handsome. Telling the true I am really-really ugly.

  • Reza Rahman Monday, July 9, 2012

    The mentality that only SpringSource and RedHat innovate is downright dangerous. The truth is that innovation inside and outside the JCP comes from a very diverse sources, including independents, Apache, small commercial companies and yes, companies like Oracle and IBM as well (indeed, in terms of direct investments, Oracle by far is the largest contributor).

  • jD Monday, July 9, 2012

    @Reza Rahman,

    I totally agree with you...

    Many-many sources have contributed to the greatness of the Java programming language and its derivatives.

    I apologize for my unintentional omission. I believe it happens in big part for the blog subject in first place.

    I almost sure that the revenue generated by Java ecosystem has paid off these contributions and more.

    Thank you

    jD @ http://pragmatikroo.blogspot.com/?view=timeslide

  • Hal Monday, July 9, 2012

    Would that Arun would provide a mechanism so I can no longer receive email updates on this thread. It's like a roach motel.... I can't check out...

    I fear I'll be getting dueling fan bois comments for all eternity.

  • jD Monday, July 9, 2012


    I agree with you to the roaches thingy...

    I think it is your fault. What you think you are going to get when you subscribe to a webblog like this one.

    roaches vs mantis?

    I've been in roaches infested hotels. I know exactly what you mean.

    Next time just don't subscribe or make sure you can unsubscribe anytime.


    jD @ http://pragmatikroo.blogspot.com

  • guest Wednesday, July 11, 2012


    You spend a lot of time discussing file sizes. In fact it seems to be the main point justifying your conclusion.

    I'd love to hear more about why this is an issue. I personally have spent very little time due to this. Can you enlighten me as to what real world problems you have observed? I'd love to know.



  • Reza Rahman Wednesday, July 11, 2012

    I agree that this thread is very stale. Anything that anyone has a genuine interest in knowing is either already in Arun's post/other resources he has referenced (that one can take as a starting point of their own independent research).

    From a Java EE standpoint, the few remaining largely non-technical "points" deserve detailed discussion on their own space, separate from this topic and focusing on persistent misconceptions about Java EE/the JCP vis-a-vis reality.

  • Luk Synergetics Thursday, July 12, 2012

    So.. you work for Oracle and you think an Oracle product is better than a competing product. That's purely coincidence I suppose.

  • Reza Rahman Thursday, July 12, 2012

    FYI Java EE is not an "Oracle product", it is an open standard maintained by the JCP (of which SpringSource is also a participant). Also note the earlier comment about independents vs. vendors referenced by Arun that have basically all arrived at the same conclusion, not to mention all the folks now adopting Java EE 6...

  • guest Wednesday, August 8, 2012

    why cant i call my favorite IDE Net Beans as legacy after it was acquired by ORACLE!!

  • guest Wednesday, September 12, 2012

    Arun, thank you for this summary of your point of view. In fact I really believe that it is more your personal attitude and very subjective review, or a at least very commercial.

    Personally, I am a friend of choosing a best fitting tool to solve a specific problem. Look, in real life you have many options to loosen a rusted bolt - a most fitting tool (which you can handle best) will make it most efficient ( with minimal distruction to the bolt, in case it is a matter ).

    In your comparison results ( the table Java EE 6 vs Spring ), for instance, you've covered apsects which are not of interest unless one want to develop on an embedded system with limited storage, nowadays, in enterprise world this is not a concern any more. In that table above I really miss the comparison in performance and heap consumption of a deployed application (not its cold/warm startup times).

    If one have his application built on Spring then it will really "behave" similiar - mostly having the same performance and memory footprints across any of target platforms / containers, because the application is driven by the same implementation core.

    But if you build against JEE6 - be sure, that its performance will vary and depend on the target platform - taken the 14 application servers from your example will all give different performance/memory footprints, because almost every of those application servers have own implementation and own bugs and require own workarounds in case of issues, this is solved with Spring - fix once, run everywhere.

    Another aspect is also if you cannot simply code against API, like in JPA, to tune the JOINs it is not enough to use JPA annotations and let the implementation decide - you have to write custom code to extend the underlying implementation and then it really matters, if you use OpenJPA or Hibernate as JPA provider.

    In my opinion it is a wrong way to go to generally take a decision on any of available frameworks - it all depends on the specific target project and the problem to solve. It may even happen, that inside the same company a "project A" is realized on JEE while for a "project B" it turns out best to go with Spring.

    Another fact is also, that people keep developing with Spring for years, not only because there was no alternative in the past but just because there is / was no reason to change a framework for the future (may be).

    If you want to promote Java EE 6 to compete against Spring, you could migrate any Spring-based application causing headaches to their developers and focus on that topic to solve that particular headaches and this way to generate value over using Spring.

    [this is really my personal opinion]

    with best regards,


  • Yotam Wednesday, September 26, 2012

    I don't really agree with this post but I am impressed by the great number of comments it gained...

    Well done!

  • Spring Lover Friday, October 12, 2012

    Mr. Arun i'll pay you more than oracle if you will promote my Spring, as i am son of rod jhonson.

    My no is 2420

    Call any time

  • guest Monday, October 29, 2012

    There are many articles about this topic that seem more like a religious war than a serious technical discussion. This one is not an exception. But as the war has started I won't be out of it

    The great problem is that most of the parameters used in the article to compare javaee 6 and spring are irrelevant (WAR size, number of jars, size of libraries ...), and some are simply false (Number of LOCs in XML files).

    About the reasons that are really important:

    * Memory usage: The comparison is quite unfair, as spring apps may be executed in simple servlet containers like Tomcat and Jetty while JavaEE 6 needs a full blown app server. Try Tomcat+Spring vs Glassfish+JavaEE6. That would be a fair comparison.

    * Freedom to choose container: You try to sell the freedom to choose container as an advantage. For me, the real advantage is being able to choose the vendor of each individual spec of JavaEE6 (At leat for those where vendor extensions are important). IE: If I use JBoss, I must use hibernate as JPA vendor and Richfaces as JSF2 implementation. What if I want to use hibernate+primefaces? The real problem with many of the J2EE "standars", is that many of them are not standard at all, just a set of specs by oracle, IBM and JBoss, which doesn't make them an standard at all. True, some of them are true standards like servlet or EL, but for many of them like JPA2 or JSF2, the true value is in vendor extensions, but once you make use of vendor extensions forget about container portability. As a conclusion, being able to choose the individual implementations is far better than being able to choose container (Which is something I can do anyway). Sure there are some risks in this approach. I agree that is responsability of the development team to make sure everything works together, but this is both an disadvantage and an advantage: What happens if you find a bug in your JPA implementation. In such cases, I prefer to upgrade my app, than to upgrade my server

  • guest Tuesday, October 30, 2012

    @Spring Lover, Let me join you to pay Mr. Arun promoting spring pls.

  • guest Sunday, November 25, 2012

    It almost seems like the real question is....What do you expect a J2EE container to give you out of the box(feature/function). The container providers are trying to provide value and sell it to a standard because they know that is important to the community to be portable(whether or not it is in reality)

    Do you believe the container is just a java application that handles threads?!?!?!? Do you want it to manage connection pools? Clustering? With spring, you can include jars to do alot of that for you so it can be done in a non-j2ee conatiner but then whats left in the container and why would we use it?

    Do you expect the container to help you monitor the health and welfare of your application? If so, what interfaces into your application can be defined in a standard way to monitor the health and welfare(MBeans on EJB instances, etc)? Do we have enough with that basic JDK monitoring and probing features?

    Without some sort of standard, you cannot ask an application container to do much for you. Hard to tell if the community would prefer it that way.

    I have done both spring and j2ee applications. It seems like the more we follow some standard the container vendors agree to follow, the more features the container can give us without having to configure it ourselves. Seems like a reasonable thing to take advantage of when we can.

    It would be nice to see a solution where we take advantage of what is their but, when the standard doesn't support it, or the container doesn't support it, we can have a solution to extend the container until a standard is defined.

    My only head-aches is if we have a new version of some library, we have to force the class-loaders to do weird stuff with our container so it doesnt try to use the built-in jars(happend to us when we went to JPA2 when weblogic did not support JPA2 yet). This is something i hope the container vendors or community can resolve so we still have both as a choice. Reversing the system class-loader is a harsh solution for that problem I think.

    From that point, let the chips fall IMO.


  • guest Sunday, December 30, 2012

    the real problem for the spring people is that they don't wanna pick up new stuff, that's all.

  • guest Sunday, December 30, 2012
  • guest Wednesday, January 23, 2013

    Spring works very well on our distributed service based Jetty/REST/Spring infrastructure. Each service uses the bare minimum Spring dependency jars to keep memory footprint low and allow auto-scaling additional services to start faster so we can efficiently add and reduce processing power very quickly.

    Some services just need Jetty and don't use Spring at all.

    We try to stick to 'best practice' where possible (JPA, CDI, JAX-RS) and prefer respected 3rd party libraries to Spring if appropriate (e.g. Camel in preference to Spring Integration) all held together by Springs extremely sensible IoC that everyone understands very well indeed.

    What would a JEE container give us that we don't already have other than migration costs, migration risks, retraining costs of existing (and new) developers and bloated application servers meaning we need to provision more servers at additional cost to support our (very large) user workload?

    Are there any JEE success stories that you can highlight showing lower development costs, lower support costs, reduced complexity, higher throughput, and improved stability over Spring?

    Spring has never let us down and is an elegant 'take what you need' model - we discuss JEE every 6 months or so (as a serious review, we are pretty good about keeping our stack as lean and modern as possible) and we are yet to see a single thing that helps us do a better job than Spring already serves us with.

  • Robert Morschel Thursday, January 24, 2013

    I'm not sure it's appropriate to start thanking Spring as if they are no longer relevant. Many companies are still using Spring for a light-weight Java or Tomcat container without having to couple themselves to a particual JEE offering. I think this particularly true in environments full of RESTful services.

  • Amit Sunday, February 3, 2013

    Its really surprising to see so many folks defending their favorite tech with so much passion. Like it or not, everything in the technological realms will be replaced in the coming yrs. If JavaEE doesn't replace Spring then something else will. Just like Spring replaced JavaEE. We might like only one way of doing things. But that doesn't mean there's no better way than that. No single piece of tech is going to last for eternity. The real point of concern is open vs controlled development paradigms.

  • guest from russian border Thursday, February 7, 2013

    I am really newbie and tried EE6 for 14 days and Spring for 30 days. Learning curve of Spring is unblievable long! At least two times longer than EE6. I can't release a small application using Spring until now. But I released much bigger real-world application using EE6.

    I can't configure Spring3.1 properly. There exists no working example by now! For 2.5 yes but for 3.1 & 3.2 no!

  • guest Tuesday, February 19, 2013

    jejeje......... JavaEE 6 came from Spring; don't forget it, Oracle

  • guest Wednesday, February 20, 2013

    Like many experienced developers I remember the time before Spring, how terrible EJB2.1 was, and the introduction of Spring (and hibernate too!). What a breath of fresh air that was. Must have rolled off 5-10 serious enterprise projects in succession with the Spring framework between 2004 - 2009. I recently headed up a large scale project for a major insurance company, starting out predictably enough with a Spring implementation. Eventually EJB3 stateless beans were introduced as service facades (the ease of container security integration, and web services were a couple of reasons). Then gradually a new JEE6 "feature" was added seamlessly to the solution and pretty soon it became obvious that Spring was actually just getting in the way. We drastically reduced LOC, complexity, configuration files, dependencies, deployment artifact sizes, and productivity soared. Even in container testing is easy now (arquillian is one approach). Haven't found a genuine reason to even consider Spring in future enterprise projects unless it is for legacy reasons, or at the behest of an uninformed Client. This is not trolling, this is just stating facts. I was a Spring evangelist for many years. But you can't deny the truth when you know it to be fact. For new enterprise projects JEE6 should be your first choice. Advice from someone who has won many battles in the trenches using Spring in the past.

  • guest Thursday, February 21, 2013

    "Its really surprising to see so many folks defending their favorite tech with so much passion" - unfortunately it is not. The day the Internet bubble has gone each and every technology turned to be a Job Safety Technology at the same time.

  • guest Thursday, February 21, 2013

    Sorry to inform you that since you started this discussion last year, you convinced me to take the opposite direction... moving away from your church.

    Here's why:

    - For freedom: I want control over my applications, I don't want to depend on server administrators that decide when I should use JEE6. it was 2012 and still on Jboss5/JEE 5. Fortunately I could migrate my apps to Spring 3, and guess what? I could even get the best of both worlds by using individual JEE 6 libraries straight away and run on Tomcat 7 with support for websockets. Restful with spring MVC and websockets is awesome. Oh! websockets have to wait JEE 7, right?

    No more waste of money to support Redhat/Jboss, Weblogic/Oracle or IBM/Websphere. you know Glassfish is used only for development. Free Reliable Tomcat is enough.

    - Separation of concerns, security, web, repositories of any kind, transactions, with Spring and good practice you never interlace these layers. You build your app with independent modules that you assemble as a Lego structure. If you need to change, say security provider or database vendor, it's a question of couple of lines change in the configuration. You want to change the design of the web UI, you not even need to touch you java code, let it to the web designer to decide, No JSPs, No (God forbid!) JSFs

    - Credits to Spring folks: without these geniuses, maybe no JEE 5 or 6, and maybe no JEE at all. Oracle should be the least grateful that JEE team got inspiration to implement and build on Spring ideas and ideals.

    - Spring is not only dependency injection, @autowired or @Inject doesn't matter, beyound that , Spring gemstone has many other facets that make your development journey pleasant and insipiring: to name a few, Spring Mobile, Spring Integration, Spring Data(Sql or NoSql it's no more a question), Spring Batch. Oh! Oracle is planing to ship batch support with ... version 8, right?

    By preaching from inside your church you bring to you only true belivers from your own church that are already convinced. Let people choose buy there own!

  • guest Monday, February 25, 2013

    you'r wonderfully JEE godfather!

  • guest Wednesday, April 24, 2013

    no way

  • Agung Setiawan Saturday, May 25, 2013

    okay, i will learn Java EE after Spring or at the same time

  • guest Wednesday, June 5, 2013


    Has anybody done their java online training from http://www.wiziq.com/course/12145-the-6-week-complete-java-primer-with-training-certificate ? I am planning to do my 6-week training on java from this site. If anybody has studied from this online java course please let me know....

  • Stephane Wednesday, June 19, 2013

    It's funny, right from the start, reading it, this blog article seemed to be biased, and sure enough the FUD was dished out on every paragraph. I guess it's not surprising coming from a demographic that lives off consulting for big gun projects.

  • Arvind Kumar Avinash Monday, September 9, 2013

    Excellent comparison and an eye opener! Thanks Arun!

  • dan Wednesday, September 18, 2013

    "Lastly, deployment size matters less on disk, and more about time to deploy, re-deploy, undeploy, etc. in iterative development cycles when dealing with larger deployment units."

    Where have you been for the last ten years? Deployment to UAT happens a couple times a day at most, if you're lucky once a week. Most testing happens in the development environment where i run unit tests and integration tests under an embedded container to catch issues before the product goes for actual user testing.

    The actual time to copy the end war to the uat or prod server is irrelevant. Inability to upgrade components as needed without a full server version jump? Now that is a big issue.

  • Dan Wednesday, September 18, 2013

    "A bug is fixed in one of the JARS, go test the custom stack again ? "

    How is that any different to "a bug is fixed in your JEE server, go and test again"?

Please enter your name.Please provide a valid email address.Please enter a comment.CAPTCHA challenge response provided was incorrect. Please try again.