Java EE 6 xor Spring
I get asked over and over again about my opinion about Spring "vs." Java EE. There is no "vs." rather than "xor". Java EE 6 is similar to Spring. Java EE 6 comes even with the JSR-330 - a Dependency Injection specification led by Rod Johnson. The main difference between Java EE and Spring is the "philosophy" behind. Java EE 6 does follow the "Convention over Configuration" or "Configuration by Exception" idea - what appears for Spring guys as Voodoo (had a long on-stage conversation with Juergen Hoeller just about that) e.g. EJB 3.1 are "just" transactional without any further ceremony. Spring on the other hand relies on explicit configuration. "Convention Over Configuration" vs. explicit configuration, however, never decided in my projects, which platform to use.
The "support" or "maintenance" policy question made the decision in last few years. It seems like developers and managers don't even know, that Spring comes with well defined SpringSource Enterprise Maintenance Policy. You will have either to upgrade to the current version of Spring (read the policy for more details), or buy a support contract. Both are valid approaches - your sponsor / manager / client just have to know about that.
There are similar policies for Java EE servers as well - so your management will have to decide which contracts to buy - or whether to go with unsupported system into production. Regardless how well it may or would work, this is not a development, rather than "political" / "strategic" decision. Given that both platforms are rather similar it is just crazy to buy both contracts.
If you go with Spring - I would use the supported tc Server: Lightweight Application Server for Cloud and Virtual Environments. It comes with nice out-of-the-box experience and professional support from single vendor.
I would always prefer the tc Server, over "custom" Tomcat+Spring configurations...
[see also Java EE 6 (CDI / EJB 3.1) XOR Spring Core Reloaded]
As you know, the JSR-330 does not work "standalone". For JavaEE the "glue" is the underlying CDI implementation. Other usage are possible (as in Spring) as well:
http://matthiaswessendorf.wordpress.com/2010/01/19/dependency-injection-the-jsr-330-way/
Even using the CDI provided scopes with Spring is pretty simple:
http://matthiaswessendorf.wordpress.com/2010/05/06/using-cdi-scopes-with-spring-3/
It's quite nice to see options to use JavaEE APIs in Spring.
Posted by Matthias Wessendorf on September 13, 2010 at 01:06 PM CEST #
@Matthias,
yes JSR-330 is just a JSR - and needs an implementation (currently weld or openWebBeans).
There are many interesting options out there- the question is whether we should make our projects interesting, or just simple :-)
thanks! at see you at JavaOne?
adam
Posted by adam-bien.com on September 13, 2010 at 01:11 PM CEST #
Yes, I am arriving on Monday night in San Fran.
CU there!
Posted by Matthias Wessendorf on September 13, 2010 at 01:13 PM CEST #
Great stuff you got here. Agreed with you that using the CDI provided scopes with Spring is pretty simple.
Posted by miller on September 13, 2010 at 10:16 PM CEST #
I think the issue with JSR 330 is not that it doesn't have an implementation, Google Guice is listed as the reference implementation. I think the issue is that there are so many things about the nature and behavior of injection that are not worked out in the specification. For example, are the injections performed when the application starts, when the object is created, or when a method from the object is called?
These are the things that are spelled out explicitly in the JSR 299 specification which is why I think the JSR 330/299 combo will be a better experience. With only JSR 330 you are really going to be writing your application according to the behavior of the implementation and not really getting any support from the spec. Of course Spring is probably happy that they can now say Spring applications are "standards compliant" when they really aren't, Spring continues it's history of saying "we can do Java EE better".
As Adam has pointed out before I think there are going to be two camps of projects going the Spring/tc Server route or the Java EE 6/app server route. I did a joint presentation at the last IBM Impact conference on comparing open source Tomcat usage with various IBM options. Even though the bulk of our discussion was saying "you don't want to be using Tomcat on your own" many people thought it was only a WebSphere sales pitch. When someone asked about tc Server I was quick to point out that might be a valid option and that we just hadn't seen a lot of people using it yet but that it would probably become more popular and solved the "don't do Tomcat on your own" problem.
I think the bigger problem is going to be that since JSR 330 doesn't have the behavior of dependency injection in the specification we are going to see a split between the Spring/330 approach and the CDI/330 approach. Of course this aplit has always been there and now we just have two options. I think this is one of the reasons correctly pointed out by IBM when they voted against the final versions of 330 and 299.
Hopefully we can bring these two approaches to DI together in the future and just have some kind of options in the specifications about the behavior aspect. This might still give implementations choice but at least standardize the possible models.
Posted by Stuart Smith on September 13, 2010 at 11:34 PM CEST #
I respectfully disagree. We use a custom Jetty/Spring stack and it works great (plus great to use with Maven).
The part you miss in the Spring vs JEE discussion is all the Spring helper classes, like JdbcTemplate, etc.
I don't think I could do raw JDBC anymore after getting used to it.
Spring Security is also quite more advanced than the JEE security mechanisms (at least the last time I checked, Java EE 6 may have added something in that regard).
Posted by Jacek on September 14, 2010 at 02:21 AM CEST #
It should be clear by looking at springsource.org that the Spring ecosystem is huge and getting bigger. JEE6 is really only a small subset of the whole picture. I would estimate the whole Spring world is about 20X bigger than JEE6 itself. As one piece of evidence, Spring encompasses all of Groovy and Grails.
If you take a look at the top level projects it's really amazing how much is packed into one company.
Posted by tim on September 14, 2010 at 03:27 AM CEST #
Sorry to say this, but this post is, in my opinion, more a TC Server advertisement than what it says in the title.
Regards
Kris
Posted by Kris on September 14, 2010 at 10:23 AM CEST #
Well JSR-330 was not that much lead by R.J but he was quick to join the effort (it can't be in his interest to stir confusion in the EE camp, now can it? Especially not after he joined the JCP to add openness, can it?) after Bob Lee didn't agree with the spec lead of JSR-299. Heaven knows why JSR-330 was even accepted, perhaps the community was just tired of fighting over it...
But I agree, Spring and EE 6 are so similar, there is no longer any reason to choose one over the other for features (present or easily implementable). Now it's more "which one is an open standard?" and in that category EE 6 is a clear winner.
It's a shame the Spring guys never brought their ideas to the JCP. It's of course OK for R.J. to make money from it and for that one can only congratulate him. But he should not have gotten greedy and tried to act like the great JCP-savior and then pull the JSR-330 supporting stunt. If all (powerful enough) members make shadow-JSRs as soon as they don't agree with the spec lead, it's no good.
Posted by Nik on September 14, 2010 at 12:47 PM CEST #
@Kris,
this post was not intended to be a TC server advertisement. If I would have to choose between Spring and Java EE 6, I would always consider to use the TC server and not the Tomcat + Spring patchwork.
thanks for sharing your opinion!,
adam
Posted by adam-bien.com on September 14, 2010 at 01:03 PM CEST #
@Jacek,
you cannot disagree this time :-). Although Jetty / Tomcat / Spring do work well - a TC server is easier to install and is officially supported by SpringSource, VMWare. You customer / client / manager has to know this.
thanks for your comment!,
adam
Posted by adam-bien.com on September 14, 2010 at 01:05 PM CEST #
I agree, Spring and EE 6 are so similar, there is no longer any reason to choose one over the other
Posted by 182.1.103.84 on September 16, 2010 at 10:20 PM CEST #
Great Post, I'm trying to learn this. Your web give me a reference to be considered. Thanks
Posted by admin on October 11, 2010 at 09:10 PM CEST #
hello Adam, I really like the info in your blog.
But I searched for JAAS and could find nothing.
please do you know any tutorial that uses JSF, EJB and JAAS? All i can find is jsp and JAAS or JAAS in JSE.
thank you very much
Posted by victor on October 30, 2010 at 03:16 AM CEST #
Well JSR-330 was not that much lead by R.J but he was quick to join the effort (it can't be in his interest to stir confusion in the EE camp, now can it? Especially not after he joined the JCP to add openness, can it?) after Bob Lee didn't agree with the spec lead of JSR-299. Heaven knows why JSR-330 was even accepted, perhaps the community was just tired of fighting over it...
But I agree, Spring and EE 6 are so similar, there is no longer any reason to choose one over the other for features (present or easily implementable). Now it's more "which one is an open standard?" and in that category EE 6 is a clear winner.
It's a shame the Spring guys never brought their ideas to the JCP. It's of course OK for R.J. to make money from it and for that one can only congratulate him. But he should not have gotten greedy and tried to act like the great JCP-savior and then pull the JSR-330 supporting stunt. If all (powerful enough) members make shadow-JSRs as soon as they don't agree with the spec lead, it's no good.
Posted by Miller on January 05, 2012 at 12:40 AM CET #
Great Post, but as i think it's looks spring TC Server advertisement from post Title.
Posted by 202.63.199.74 on October 15, 2012 at 04:21 PM CEST #