i read a lot of blogs and newspages about the toppic Spring vs. JEE6
- The weaknesses of the old J2EE (around 2002) which was the justification for using Spring is longer valid for JEE6. But the weakness of the old J2EE was the justification for using Spring instead of J2EE. Thus, the justification for using Spring fell.
- Spring itself is based on JEE, so why not just use JEE directly?
- It is possible to use J2EE and Spring together in the same project, but it only increases the complexity and has no added value. One should decide for using one of them in a new project.
- JEE 6 with a current application server eg. JBoss AS 7 has not really significant higher resource consumption as the combination Tomcat + Spring, quite the opposite.
- In Spring there is the so-called JAR Hell the counterpart known from the ancient world of Windows DLL Hell. In JEE 6 not.
- JEE6 has adopted the advantages of Spring and other frameworks and optimized it. Spring was just used to fix the issues of J2EE (1.2/1.4).
- For new development projects you should use JEE only. You donï¿½t mix Spring and JEE 6.
- For existing Spring applications, it may make sense to use still Spring.
What is your opinion about the following blog-posts?
Blog von Harald Wellmann
Deconstructing Spring myths Over the past five years, I have had the pleasure of working on different Java enterprise projects based on OSGi, Java EE and Spring. Among these three platforms, Spring is the one I'm least happy with.
But somehow the glory of Spring's founding myth of killing the beast that was J2EE seems to be fading. The former
beast is now as manageable and easy to use as Spring ever was, or even more so. Dependency Injection in Java is no longer synonymous with Spring (and in fact never was).
There is no Spring without Java EE
Most debates about Java EE vs Spring sound like an either-or question, but this is a misconception. You can build an application on Java EE without ever using a Spring API, but you can't really build an enterprise application on Spring without using a number of Java EE APIs and implementations.
In the age of AJAX and component-oriented web frameworks, Spring MVC feels rather old-school. JSF 2.1 has a lot
more to offer, and if you prefer an independent web framework like Vaadin, the underlying container does not matter
And finally, CDI is much more powerful that Spring Dependency Injection, due to its seamless scope handling, its event model and its portable extension mechanism.
Spring has no clear separation of API and implementation, neither at specification level nor at code level.
By contrast, Java EE is first and foremost a set of specifications, represented by a collection of thin API JARs or an all-in-one javaee-api.jar. There are different independent implementations by different providers. Provider specific
implementation classes are not normally visible to the user.
With Spring, there's only Spring. You can't swap framework components. You can't even cherry-pick framework
components. There is insufficient separation of concerns. Inherently, there is no reason why a web framework or a
NoSQL persistence provider should have to be tied to a given dependency injection container.
Java EE means one-stop shopping for the core functionality of an enterprise software stack. javaee-api.jar provides the interfaces you need to start developing your own applications. All the required runtime environment is provided by the application server.
My current project is a Spring web application deployed on Tomcat. The final WAR has more than 100 JARs in WEB-
INF/lib. More than 30 of these JARs are due to Spring itself, its dependencies or other Java EE components not provided by Tomcat.
In other words, by moving from Spring to Java EE, I could drop a third of the dependencies of my application. And I'm not talking about saving 30 megabytes of disk space, but about the effort of maintaining these dependencies and resolving version conflicts of transitive dependencies.
The flip side of JAR hell is configuration hell. With Spring, once you have gathered all required components, you also
need to configure them.
With Java EE 6, little or no configuration is required. Transaction management works out of the box.
The fact that Spring beans are singletons and not thread-safe by default tends to promote a rather ugly procedural
Blog von Adam Bien
There is no need to switch from one to another in already running projects. In greenfield projects (=where you are
beginning from scratch) however, you have to make a clear distinction for the core part. Between Java EE 5/6 (not J2EE) and Spring,there is too much overlap in the core Dependency Injection part - "JSR-330 Dependency Injection For Java" is supported by both platforms. There is no added value to run the Spring core part (Dependency Injection) on top of the Java EE 6. There is also no added value to run CDI on top of the Spring framework.
Blog von Arun Gupta (oracle)
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!
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
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.
Blog von Bill the Plumber
I remember internal JBoss emails 4-5 years ago arguing whether we should give upon promoting Java EE as a component model (aka on EJB) and just concede to Spring. Now, 4-5 years later, Java EE 6 has answered the challenge and is a viable, rich, integration technology.
Spring was and has always been a wrapper over core middleware infrastructure: ORM, Transactions, Messaging,
HTTP. It always depended core Java EE specs like JPA, JTA, JMS, and Servlet. So, since you couldn’t deploy a Spring app without at least one of these core technologies/specifications, Java EE stayed in users minds.
Blog von Kai Wähner
Usually, the crucial question is: „Should I use JEE (i.e. especially EJB, JPA, CDI, etc.) or the Spring core
framework (i.e. especially Spring Application Context, Spring beans, etc.) for realizing my new
application? Mostly, you can choose both, it does not matter from the point of view of the end user.
But you should not merge both, this only creates higher complexity.
Today: J2EE is dead. JEE „stole“ the lightweight Spring ideas!
Everything started with a little shortcut change. J2EE was dead. The new shortcut was JEE. JEE 5 was
born in 2006. It „stole“ many good, lightweight ideas such as „convention over configuration“ or
„dependency injection“ from Spring and other frameworks.
Blog von Thomas Schütt (Softwareentwickler im Bereich Enterprise Java)
Artikel bei TheServerSide.com: Moving to Java EE 6: The Age of Frameworks is Over
There is no arguing the fact that TheServerSide.com has historically been a strong advocate for the work of Rod
Johnson and the Spring framework.
The J2EE platform had its shortcoming, and Spring quickly became the most prominent and pervasive framework for
easily building enterprise-ready applications,…
But J2EE represents the past, and Java EE 6 represents the future. Java EE 6 promises us the ability to go beyond
Frameworks like Spring are really just a bridge between the mistakes of the J2EE past and the success of the Java EE 6 future. Frameworks are out, and extensions to the Java EE 6 platform are in. Now is the time to start looking past Spring,and looking forward to Seam and Weld and CDI technologies.
Artikel bei howtojboss.com, Article Series: Migrating Spring Applications to Java EE 6 – Part 1
The technical reason is that upgrading your old-school Spring applications, even to modern Spring-based solutions,
requires a lot of work anyway. Some technologies that might be used in the original application might even be
considered end-of-life soon, or worse, are already part of a dark past.
When we mention “old-school Spring apps” we picture lots of complex XML configuration, an outdated ORM solution
like JDBC templates, Kodo, or TopLink, and an old fashioned approach towards the web using a deprecated extension based Web MVC SimpleFormController.