Why using Spring instead of JEE6?

Hello,
i read a lot of blogs and newspages about the toppic Spring vs. JEE6

my conclusion:

• 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?

Blogs:
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
anyway.
…
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.
…

JAR Hell

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.

Configuration Hell

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
programming style.
…

http://hwellmann.blogspot.de/2012/05...ing-myths.html

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.

http://www.adam-bien.com/roller/abie...a_ee_6_cdi_ejb
http://www.adam-bien.com/roller/abie...e_6_xor_spring


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.

https://blogs.oracle.com/arungupta/e...y_java_ee_6_is

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.

http://bill.burkecentral.com/2012/03...s-over-spring/

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)
… http://thomas-schuett.de/2009/09/24/...a-ee-reloaded/

Artikel:

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.
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.

http://www.theserverside.com/discuss...hread_id=61023

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.

Hello

First - about these blogs:

Quote:

---

Blog von Harald Wellmann

... But somehow the glory of Spring's founding myth of killing the beast that was J2EE seems to be fading. ...

---

This founding myth is long gone. Looking from now it's just an episode. Now, IMO, the most important Spring's theme is flexibility, extensibility and it's ubiquitous character. Spring is everywhere and is influencing everything that's important in Enterprise world.

Quote:

---

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.

---

That's right. But the most obvious (but not direct) analogy is that you can implement a CMS system in Assembly, but you can also use Java or PHP. Java uses Assembly underneath (but you don't have to use it directly). Spring uses JavaEE APIs underneath and yes - you use them from time to time, but it's easier to use Spring's abstractions (see: JdbcTemplate, WebServiceTemplate, JmsTemplate, ...)

And (my favorite) example - please implement something serious in terms of security with Spring(-Security) and then with pure JavaEE - good luck.

Quote:

---

...
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
anyway.

---

Do you live in the age of component-oriented web frameworks? I don't. I live in jQuery(-UI) era, when throwing large viewstate from browser to server is a signal of bad taste. ASP.NET is component oriented framework and now all the hype is about ASP.NET MVC.

Quote:

---

…
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.

---

What's "seamless scope handling"? And CDI event model - it's just nice solution, Spring-Core has similar functionality. And tell me - how many "portable extensions" (beside RI and Seam) are there?

https://sites.google.com/site/cdipojo/get-started seems dead, For www.cdisource.org (announced in http://www.dzone.com/links/reza_rahm...7_and_8.h tml) someone's forgotten to pay for the domain...

Quote:

---

…
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.

---

That's in ideal world. In fact, user must know what's under. For example, In WebSphere 7 theres Axis2-SNAPHOST under JAX-WS API - are you sure it's safe not to be aware of this? And what if you'd want to use some e.g., CXF 2.7.2 functionality?

Quote:

---

…
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.

---

Of course, with JPA there's e.g., Hibernate and EclipseLink (any others?). But with Hibernate there's only Hibernate and with EclipseLink there's only EclipseLink. Believe me (I've tried) - you just can't swap Hibernate to EclipseLink without many changes to your code and build process.

Quote:

---

JAR Hell

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.

---

Believe me - not all the required runtime environment is provided by app server. And what's worse - not everything that app server provides is what you want. And it's not safe to replace some libs in app server without affecting other applications deployed therein. And don't tell me that app server should be used to deploy only single application...

Quote:

---

Configuration Hell

---

I'm currently maintaining a project that has been released in 2004 using Spring 1.0.2. Now it's using Spring 3.0.x. Nothing has changed in configuration which still (after 9 years) give me a view of project architecture and it's component's/subsystems' relations. Try do it with CDI.

Quote:

---

Blog von Adam Bien, Blog von Arun Gupta (oracle), Blog von Bill the Plumber

---

Please read my comments under their blog posts. Especially under Bill Burke's.

Quote:

---

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.

---

It's easy to write such nonsense. My 9 year old, Spring-based system still uses SimpleFormControllers but also uses modern @Controllers. I have no problem with it. And what's "outdated ORM solution"? Isn't TopLink a JPA implementation?

Since 2004 I've got rid of MDBs and session beans (EJB 2.1) in this project. Are you sure that newer versions of CDI or EJB will be easy to migrate to? Was (is) easy to migrate from EJB 2.1 to EJB 3.x?

And finally my personal opinion:

Standards are good, but APIs are not everything. You don't create new projects from scratch every day. 99% of your work you maintain existing apps. Even in Spring I was quite sceptic of @Configuration beans. They're good and I use them, but I find that after 5, 6 years it's much easier/safer to rely on what was written in XML config than on what stems from quite implicit annotation-based configuration.

Spring has such projects as: Security, Integration, Social, Data. Go and find similar projects in JavaEE.

best regards
Grzegorz Grzybek

Hello

I've posted an answer, but it hadn't shown... Strange

Hello

First - about these blogs:

Quote:

---

Blog von Harald Wellmann

... But somehow the glory of Spring's founding myth of killing the beast that was J2EE seems to be fading. ...

---

This founding myth is long gone. Looking from now it's just an episode. Now, IMO, the most important Spring's theme is flexibility, extensibility and it's ubiquitous character. Spring is everywhere and is influencing everything that's important in Enterprise world.

Quote:

---

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.

---

That's right. But the most obvious (but not direct) analogy is that you can implement a CMS system in Assembly, but you can also use Java or PHP. Java uses Assembly underneath (but you don't have to use it directly). Spring uses JavaEE APIs underneath and yes - you use them from time to time, but it's easier to use Spring's abstractions (see: JdbcTemplate, WebServiceTemplate, JmsTemplate, ...)

And (my favorite) example - please implement something serious in terms of security with Spring(-Security) and then with pure JavaEE - good luck.

Quote:

---

...
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
anyway.

---

Do you live in the age of component-oriented web frameworks? I don't. I live in jQuery(-UI) era, when throwing large viewstate from browser to server is a signal of bad taste. ASP.NET is component oriented framework and now all the hype is about ASP.NET MVC.

Quote:

---

…
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.

---

What's "seamless scope handling"? And CDI event model - it's just nice solution, Spring-Core has similar functionality. And tell me - how many "portable extensions" (beside RI and Seam) are there?

https://sites.google.com/site/cdipojo/get-started seems dead, For www.cdisource.org (announced in http://www.dzone.com/links/reza_rahm...7_and_8.h tml) someone's forgotten to pay for the domain...

Quote:

---

…
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.

---

That's in ideal world. In fact, user must know what's under. For example, In WebSphere 7 theres Axis2-SNAPHOST under JAX-WS API - are you sure it's safe not to be aware of this? And what if you'd want to use some e.g., CXF 2.7.2 functionality?

Quote:

---

…
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.

---

Of course, with JPA there's e.g., Hibernate and EclipseLink (any others?). But with Hibernate there's only Hibernate and with EclipseLink there's only EclipseLink. Believe me (I've tried) - you just can't swap Hibernate to EclipseLink without many changes to your code and build process.

Quote:

---

JAR Hell

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.

---

Believe me - not all the required runtime environment is provided by app server. And what's worse - not everything that app server provides is what you want. And it's not safe to replace some libs in app server without affecting other applications deployed therein. And don't tell me that app server should be used to deploy only single application...

Quote:

---

Configuration Hell

---

I'm currently maintaining a project that has been released in 2004 using Spring 1.0.2. Now it's using Spring 3.0.x. Nothing has changed in configuration which still (after 9 years) give me a view of project architecture and it's component's/subsystems' relations. Try do it with CDI.

Quote:

---

Blog von Adam Bien, Blog von Arun Gupta (oracle), Blog von Bill the Plumber

---

Please read my comments under their blog posts. Especially under Bill Burke's.

Quote:

---

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.

---

It's easy to write such nonsense. My 9 year old, Spring-based system still uses SimpleFormControllers but also uses modern @Controllers. I have no problem with it. And what's "outdated ORM solution"? Isn't TopLink a JPA implementation?

Since 2004 I've got rid of MDBs and session beans (EJB 2.1) in this project. Are you sure that newer versions of CDI or EJB will be easy to migrate to? Was (is) easy to migrate from EJB 2.1 to EJB 3.x?

And finally my personal opinion:

Standards are good, but APIs are not everything. You don't create new projects from scratch every day. 99% of your work you maintain existing apps. Even in Spring I was quite sceptic of @Configuration beans. They're good and I use them, but I find that after 5, 6 years it's much easier/safer to rely on what was written in XML config than on what stems from quite implicit annotation-based configuration.

Spring has such projects as: Security, Integration, Social, Data. Go and find similar projects in JavaEE.

best regards
Grzegorz Grzybek

Hello,

please try again. Thanks.

I've got a message, that the answer (rather long one) requires moderation...

Quote:

---

Originally Posted by Grzegorz Grzybek

Hello

I've posted an answer, but it hadn't shown... Strange

---

For some reason (probably due to some links) the post needed approving (as did the post from the TS). Post has been approved (approved only a single one as both replies where the same).

Quote:

---

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.

---

JBoss is using pretty much a modified Tomcat as their Servlet Container? So how should JBoss eat less ressources than Tomcat for the same application? Maybe you could tune done your JBoss hard, until (nearly) only the Servlet Container is left, but in my experience JBoss eats A LOT more ressources and starts A LOT slower, which can be really painful if not using JRebel.

Also you can't compare the new JEE possibilities with the old (xml-style) Spring-configuration. Today configuring Spring is really simple, mostly Annotations, very few XML, if at all.

Some points for Spring: Take a loot at Spring-Transaction and @Transactional, it makes transaction-management ridiculously easy. Spring-AOP is a blessing if you want to use Aspects. Spring-JDBC could still offer you something, jee-entitymanager is great too though. Spring-Test is helping a lot with writing isolated tests (with rollbacks) without headache, so is Spring-ldap for talking to you companies Active Directory (or others). Instrumentation is pretty easy as well. Also Spring-Security (while requiring some configuration) is really awesome and intuitive once you understand it.

So if you talk about the core (DI) only you are right: there is no real reason to use Spring anymore. But in the big picture Spring's flexibilty and the amount of great extensions will make your life easier.

I have not practically used JEE6, but I have seen many concepts of JEE6 taken from Spring, so its better to use Spring Framework which has implemented DI, AOP etc. long before JEE6.

I work with both Spring and Java EE 6 env.

Actually Spring helped Java EE 6 to be as good as it is now. And since competition helps to build better products I hope Spring will continue to be a separate stack instead of being "one more Java EE application server". But it's true that "j2ee is evil" is a ridiculous argument now.

But still, Spring could have been a spec leader on DI spec, just like Hibernate team was the most legitimate spec leader for JPA spec. Instead of that we have this CDI spec, which is a super factory and not a real implementation of strategy pattern. In CDI : how do you build two instances of the same object but with different injections ? how do you inject a map ? Here, xml conf beats pure annotation config.

And CDI and EJB should merge, I think. What's the point of having 2 containers ? You cannot seriously get rid of EJB (transaction, security, etc... writing custom interceptors looks like going back to the 90's). Seriously, who build apps based only on weld+hibernate+jsf on a simple tomcat ?

I like Java EE because once you accept the app server (not so big memory footprint, app reloads take in 200 ms in Eclipse), your infrastructure does not become more and more complex if you decide to use jms, remoting, web capabilities, etc... "application server" is not your ennemy anymore.

I like Spring because they does not have to wait for JCP consensus do release new librairies. For example : spring data. In the Java EE world, how long will it take to have a good api for websocket (JSR 356), a good api for noSQL, a good api for social apps ?

I think that it's not accurate to claim that "what can be done with java EE can be done with spring" or "what can be done with spring can be done with java EE". What is interesting is : what can be done only with java ee, what can be done only with spring (including gemfire, ers, rabbitMQ). And then, regarding your business requirements you make your decision.

But it's true that Java EE spec + JVM offers a n-n-n relationships between languages, app server and OS.
As said someone at a Devoxx conf, the future of java is its jvm more than its language. But it's a bit off topic.