Discussions

SpringSource announced that it has released Spring 3.0 for General Availability. Spring 3.0 features REST support, Spring expression language, extended support for annotation-based components, declarative model validation based on constraint annotations and standardized dependency injection annotations.
Spring 3.0 GA can be hosted on Java EE 6 servers. It supports JPA 2.0 final, JSR 303 validation mode and @Managed Bean (JSR-250 v1.1) annotation for component scanning.
Spring 3.0 brings new component model features. If you have a Spring-powered application, you can switch your libraries to Spring 3.0 without having to upgrade your server installation, according to the company.
“Beyond the big themes, there are hundreds of refinements in the details which you will particularly appreciate when upgrading from Spring 2.5.” said Juergen Hoeller from the SpringSource team blog.
Hoeller noted that standardized dependency injection annotations are the flagship feature in Spring 3.0. It supports the JSR-330 specification for Dependency Injection in Java – annotation-driven injection via @ Inject and its associated qualifier and provider model as an alternative to Spring’s own @Autowired and co.
Spring 3.0 comes with a new TaskScheduler and Trigger. Spring also supports @Async and @Scheduled annotations now.
Download Info:
Spring 3.0 download.
Read Juergen Hoeller's blog.
[Clarification: The original version of this news post imprecisely stated that "Spring 3.0 is now compatible with Java EE 6." The material on which the story was based indicated runtime Java EE 6 server compatibility. Editor's error.]
Greg Smith writes for SearchSOA.com
Message was edited by: jvaughan@techtarget.com

@Chief
Spring 3 implements only a subset of JavaEE 6. They never claimed to have passed the JavaEE 6 TCK, nor would they want to.
JavaEE server vendors want you to think that you need a fully compliant JavaEE 6 server to put any serious application in production, so that you may buy their server.
Struts 1.x proved that you needn't be standards based in order to succeed.

Spring 3 implements only a subset of JavaEE 6. They never claimed to have passed the JavaEE 6 TCK, nor would they want to.

So, if I use Spring 3 and "stupidly" want to use JEE 6 features and my application doesn't work as the JEE 6 spec states, then I, myself, am the only person to blame. Is that right? (because Spring 3 hasn't passed the JEE 6 TCK yet). In other words, people who want to use Spring 3, should avoid everything in JEE 6 (for example, JPA 2, JSF 2 ...). Is that right? If that's right, SS shouldn't say that Spring 3 supports a subset of JEE 6 in a generic way like that. They should indicate clearly what features of JEE 6 Spring 3 supports.

Spring 3 implements only a subset of JavaEE 6. They never claimed to have passed the JavaEE 6 TCK, nor would they want to.

So, if I use Spring 3 and "stupidly" want to use JEE 6 features and my application doesn't work as the JEE 6 spec states, then I, myself, am the only person to blame. Is that right? (because Spring 3 hasn't passed the JEE 6 TCK yet). In other words, people who want to use Spring 3, should avoid everything in JEE 6 (for example, JPA 2, JSF 2 ...). Is that right? If that's right, SS shouldn't say that Spring 3 supports a subset of JEE 6 in a generic way like that. They should indicate clearly what features of JEE 6 Spring 3 supports.

Thai,
I agree "Spring 3.0 is now compatible with Java EE 6" is a pretty mis-leading statement, intentional or not. And this is the first time they are using this kind of terminology despite having partial support for Java EE for years now. The "compatible" part is what's most troubling...
I think this is a potential legal issue if Oracle wishes to pursue it...
Cheers,
Reza

I agree "Spring 3.0 is now compatible with Java EE 6" is a pretty mis-leading statement, intentional or not.

For the record, the full wording that I used on the blog was "Spring 3.0 GA is compatible with Java EE 6 final in terms of runtime environments now (e.g. on GlassFish v3 as released last week)". It may not have been worded very clearly. Still, I think it's obvious than I was talking about Spring to be hosted on Java EE 6 servers (I even said "on GlassFish v3"!!), and about interacting with Java EE 6 API levels.
Tearing that statement out of context is quite disingenuous. Continue to read the blog entry and you'll see that I was even explicitly talking about exposing Java EE 6 APIs when running Spring on GlassFish later on. The assumption that my statement meant to say that Spring itself implemented Java EE 6 is quite ridiculous, frankly, and can only come from sources that have no clue about what Spring really is. I cannot imagine a single Spring user having misunderstood that statement. Not a single comment on our blog indicated such a misunderstanding either.
As a side note: Early JSR-299 drafts (back when it was called Web Beans still) used the phrasing "Web Beans is compatible with Java EE 5" in exactly the same way that I used it. I assume that sentence came from Gavin King himself, so it's not like the wording is completely off the track (or even a potential legal issue - wow, that's a new level of FUD - congratulations for lowering the bar even further, Reza). Gavin also said "Seam is compatible with J2EE" in his Seam 1.1 GA announcement (http://relation.to/1946.lace). That wording is more common than you think.
Juergen

Juergen,
Thanks for clarifying - just making sure this is not something that we need to worry about after all the debate over the Java EE 6 Web Profile and JSR 330 vs. JSR 299. If it's an honest slip, it's an honest slip - no one should be faulted for that...
Cheers,
Reza
P.S.: Please don't be that hyper-sensitive. I have no grudge against you/SpringSource and make it a point to be as fair as I can -- honest. For one, I've given you due credit where you really deserve it.
That being said, I will admit that it's hard to ignore the unnecessary personal attacks just because you don't like what I have to say, just like the uncalled-for "new lows" bit...

Honestly, I liked Spring in the past and what achieved in the dark times of EJB2 but now we are at the future and now the EG of Java EE 5/6 did a great job to take all the good ideas from all the projects and match something almost perfect and easy to use. I applaud to the Expert Groups for this effort.
But Talking about Spring I think they are trying to reinvent their self their own Distributed and Enterprise server. I think is now the time to leave Spring and go with the standard beacuse in the standard is for sure and now more with JEE 6 that if I run my application on Glassfish also it will run on JBoss or WebLogic or even just Jetty/Tomcat but here Spring is going in another direction already.
Spring, it was fun until lasted.
my 2c.

There is much more to Spring than ORM, IoC and transaction management (and the other things in Java EE6).

Now here is sound argument for Spring and I am assuming you are talking about the third-party tools built around Spring. I terms of Java EE, this is what the CDI SPI and portable extensions are designed for.
Specifically, what Spring "extensions" do you use heavily that would be valuable as CDI portable extensions? The JBoss and Apache guys are already developing a bunch - we can develop some nice ones too since we're almost done our CDI implementation.
Thanks in advance,
Reza

Can't no agree more.
Thanks Spring for taking us out of the dark times.
Now we finally got light with JEE 6.0, especially JSR299 (aka. CDI).
If springsource will make more money selling their own SpringAppServer, I won't be against it but go by with thanks.

Honestly, I liked Spring in the past and what achieved in the dark times of EJB2 but now we are at the future and now the EG of Java EE 5/6 did a great job to take all the good ideas from all the projects and match something almost perfect and easy to use. I applaud to the Expert Groups for this effort.

But Talking about Spring I think they are trying to reinvent their self their own Distributed and Enterprise server. I think is now the time to leave Spring and go with the standard beacuse in the standard is for sure and now more with JEE 6 that if I run my application on Glassfish also it will run on JBoss or WebLogic or even just Jetty/Tomcat but here Spring is going in another direction already.

Anyway with OSGI, what's the purpose and advantages of EJB ?
OSGI does provide a much better component model than EJB and SpringSource is quite smart to improve spring relevance in this field (osgi 4.2 with blueprint inspired from Spring DM for instance).
I see a future where osgi is prevalent and EJB is declining.

Honestly, I liked Spring in the past and what achieved in the dark times of EJB2 but now we are at the future and now the EG of Java EE 5/6 did a great job to take all the good ideas from all the projects and match something almost perfect and easy to use. I applaud to the Expert Groups for this effort.

But Talking about Spring I think they are trying to reinvent their self their own Distributed and Enterprise server. I think is now the time to leave Spring and go with the standard beacuse in the standard is for sure and now more with JEE 6 that if I run my application on Glassfish also it will run on JBoss or WebLogic or even just Jetty/Tomcat but here Spring is going in another direction already.

Anyway with OSGI, what's the purpose and advantages of EJB ?OSGI does provide a much better component model than EJB and SpringSource is quite smart to improve spring relevance in this field (osgi 4.2 with blueprint inspired from Spring DM for instance).I see a future where osgi is prevalent and EJB is declining.

I agree, OSGi is a great framework for modularization, and so, my question is...who will use J2EE6 & EJB containers?

OSGI is indeed nice. Glassfish, the first Java EE 6 implementation makes good use of it.

, and so, my question is...who will use J2EE6 & EJB containers?

J2EE6??? Never heard of it. I guess not a lot of people will use it.
EJB containers will be used more and more I think. It went from obscure technology to Java's secret weapon. Where I work we're converting more and more projects to take advantage of the elegant and now lightweight EJB programming model. Code has become fun again with EJB! :D

Spring 3 implements only a subset of JavaEE 6. They never claimed to have passed the JavaEE 6 TCK, nor would they want to.

So, if I use Spring 3 and "stupidly" want to use JEE 6 features and my application doesn't work as the JEE 6 spec states, then I, myself, am the only person to blame. Is that right? (because Spring 3 hasn't passed the JEE 6 TCK yet). In other words, people who want to use Spring 3, should avoid everything in JEE 6 (for example, JPA 2, JSF 2 ...). Is that right? If that's right, SS shouldn't say that Spring 3 supports a subset of JEE 6 in a generic way like that. They should indicate clearly what features of JEE 6 Spring 3 supports.

That's stupid. You can use hibernate Api with jpa without worrying about being JEE confirmant. Depending on feature you want it is better to stick with framework you are comfortable.
What ever comes out of sun is not always the best technology. Compare flex with javafx.

What ever comes out of sun is not always the best technology. Compare flex with javafx

This is your example? Ok. Flex issues - ActionScript, MXML, doesn't run in the JVM, tooling is "mucho denaro", must convert Java objects to Actionscript (if doing Java and OO), must duplicate business logic between front-end and back-end (Flex is a client-side technology), the event model ... I could go on.
Sure, JavaFX isn't perfect nor is it done. But not the best technology?

They never claimed to have passed the JavaEE 6 TCK, nor would they want to.

That wasn't my question. I was interested in reasons why to not vote in ballot.

JavaEE server vendors want you to think that you need a fully compliant JavaEE 6 server to put any serious application in production, so that you may buy their server. Struts 1.x proved that you needn't be standards based in order to succeed.

Again, not related to my question, but you are really missing a point. It is about standardized solutions, where all major providers agree on what platform should look like. Otherwise, we end up with fragmented market, where the end customers ends up being hurt. Choosing custom solution from single vendor when there are standardized offerings for any mission critical system is bad business decision. When I buy something from RedHat, I have standardized development platform (large pool of work force to hire, fast and easy knowledge transfer) etc, as opposed to when I buy something from Microsoft. Same applies when comparing SS and JBoss.
Regarding your Struts reference, again, you are missing the point. You can build UI in whatever technology you wish since it is generally the cheapest and easiest part of any business problem, but building middleware based solutions, such as those that require guaranteed message delivery, distributed tx processing requires standards.

The idea of CDI is from Seam, Spring and Guice. If those non-standard things didn't exist, there'd never be standards. IMO, Spring is the best non-standard, then Google with their GAE/J which doesn't have all classes of Java SE comes next.

The idea of CDI is from Seam, Spring and Guice. If those non-standard things didn't exist, there'd never be standards. IMO, Spring is the best non-standard, then Google with their GAE/J which doesn't have all classes of Java SE comes next.

I fail to see correlation between dependency injection frameworks, full blown middleware specifications, GAE and Java SE. No offense.

Esp. between DI and 'full blown middleware specifications'. People just try to push their products and/or specifications for (economically) obvious reasons. A world of salesmen, not engineers.

EE is more that just EJB and some Web UI technologies. JMS, JCR, Web Services to name a couple. When you taste costs of being bound to proprietary systems, you may start to appreciate benefits of standards.
So, it is world of engineers after all.

Thai,
I am assuming you've looked at CDI? So what in your opinion in Spring IoC or Guice is it that you think CDI is missing? As I see it, CDI is a super-set of both and has no legacy baggage. Or is that not what you meant at all?
Cheers,
Reza

So what in your opinion in Spring IoC or Guice is it that you think CDI is missing?

I haven't got a chance to play with Guice. I intended to do that many times, but the fact that Guice is a pure DI framework with no transaction managment made me think what I use Guice for (in all my cases, I can use Guice for testing only). Your question is big. I won't answer it until I know much more about CDI/Weld. One Spring feature I like is its AOP programming which is very powerful, IMO. That doesn't mean I don't like other things like DI, transaction managment ... but I like the EJB3 transaction management a little bit better.

... has no legacy baggage.

If CDI had any legacy baggage, Gavin King should be hanged ;)
PS: please take my opinions as those of an average Joe Java programmer :)

Firstly, congratulations to the Spring team on a timely and I am sure stable release.
Not to beat a dead horse since this was discussed ad-nausea in the previous Java EE 6 related thread, but it is obviously a disappointment that this release did not implement CDI and decided to only implement JSR 330. I've also found it a strange decision that they decided to create their own REST implementation bound to Spring MVC instead of simply embracing JAX-RS. Lastly, I'm unsure why this qualifies as a major release given the relatively small amount of new features really - perhaps the partial Java EE 6 support is important symbolically - who knows?
That all being said, I am glad the SpringSource folks see the value in JSR 330, JSF 2, JPA 2 and bean validation.
Best wishes for the New Year,
Reza
---------------------------
Author, EJB 3 in Action
Expert Group Member, Java EE 6 and EJB 3.1
Resin EJB 3.1 Lite Container Lead

Not to beat a dead horse since this was discussed ad-nausea in the previous Java EE 6 related thread, ...

Ah, but yes, you are beating a dead horse, in fact you are beating it again since you have expressed your erroneous opinion in other threads as well. Perhaps we should call PETA to report the abuse?
Responses to your comments already exist here and here for those that don't want to rehash it all in this thread. Your concern about what qualifies as a major release has also been addressed not just by Juergen but also by other knowledgeable observers.
Adam FitzGerald
SpringSource

I guess they are more interested in slandering me and Gavin because we don't think Spring is "end all be all" or asking questions about the concrete reason they didn't go the CDI route, beyond "it's too hard" and "we can mind-read all the Spring developers in the World and they said they didn't need it" :-).
Cheers,
Reza

Reza,
I am working in one of the world's largest financial firms and have no affiliation with Spring Source. I am a very happy Spring user and not anti-JEE. Not just I, the entire team is happy with Spring and I would even go as far as to say that no new projects are started without considering Spring and in most of the cases adopting Spring. The reason Spring is so obvious choice, is because:
1. Adopting earlier version of J2EE made not just the development miserable but a maintenance nightmare.
2. I personally worked on projects that were re-architected from an EJB based to a Spring based solution and running fine in Production for more than 4 years without any issues that were caused by earlier JEE compatible implementations.
Now, I understand that I am basing my arguments on an earlier version of JEE and not based on the merits of JEE6.
My point is, just as Spring has to prove its worth and return on investment before its wide spread adoption, JEE6 has to prove its merit. You and Gavin bring up the same questions on 5 different forums and saying Spring is not implementing CDI and so you have to use JEE is not helping either. Also lot of Organizations have invested heavily on Spring and to move away from that you really need to give a better technical reasoning than saying Spring is NOT JEE compatible. As of yet, we do not have any technical reason to move away from Spring. And, we don't really care that our application is JEE compatible as much we care about simplicity and maintenance (we are like that past 5 years or so and our applications are doing just fine). Again, this is just my experience over a decade long career implementing critical enterprise applications in Java (a lot of my friends working in even smaller Organizations have the same opinion) but yours could be different.
Now, help me understand this:
1. Why would I move away from a Spring based solution which I can run on any server to a new spec that has no single production application implemented yet? (Lot of our applications run on WebLogic and recently we are moving towards tomcat based solution)
2. What is that I cannot do with Spring that I will be able to do with JEE 6? I don't buy the argument of portability because my Spring application is really portable to any app server.
3. The most important of all: Other than saying, we are not JEE compatible, which my business users don't care, what is the argument for me to go to my business and ask for money so that we can start the new projects ground up using JEE6 and forfeit the investments made so far in Spring?
I hope you can help me answer this questions so that I get a better understanding. Thanks.

Here here. The criticism of "it's not JEE 6 compatible" doesn't hold any weight. I also recall the promises of J2EE's portability that were only realized when we switched to a Spring-based architecture. I'm sure that things have improved but as of yet I don't have any truly compelling reason to want to switch back, especially with the standards world in a bit of a grey area with the recent Oracle purchase of Sun.
I've never understood why the JBoss people and others have been so violently anti-spring. Using Spring doesn't prevent me from buying another app server. Those decisions are usually made based on reliability and support, and it's nice to have a way to develop that allows those decisions to be isolated from the technical decisions. Spring provided that for years, and while changes to the JEE specs may provide it now, that's no reason to bash Spring.
And in the spirit of full disclosure, the only reason I'm a supporter of Spring is because it made my life so much easier in so many situations over the course of years.

Here, here +2
To the Spring bashers that have been exhibiting their opinions on various threads over the last week you should remember that Spring has a very large base of 'satisfied customers'. Patronizing the 'Spring fan boys' etc, and the a general tone of 'you must be really stupid to keep using Spring now' is one way to make sure that the Spring user base continue to look to Spring first for their technical solutions. Well done.

and the a general tone of 'you must be really stupid to keep using Spring now' is one way to make sure that the Spring user base continue to look to Spring first for their technical solutions. Well done.

Not sure what you mean exactly? Are you implying people who use Spring are not smart...
People will look to Spring first because it has solved their problems before and the result was good for their business. Is it not smart to look again at Spring to solve a new problem and see if it offers a solution?
Of course I am dumb. What would I know....

People will look to Spring first because it has solved their problems before and the result was good for their business.

You mean people who have used Spring in the past? Not people in general. People in general have used Java EE in the past, and they're thus again looking at Java EE when starting a new project. If they see that the direction Java EE has taken (Java EE 6 in this case) is a good one, they will probably use Java EE again, since they have seen good results from it in the past (Java EE 5).
Of course, people who are interested in technical stuff will check out Spring anyway, just because learning a new tool is cool. They will probably also check out .NET and maybe Grails, or RoR.
It's not 'wrong' to use Spring. It's a good tool and if you're happy with it, the better for you. Maybe you would care to explain what part of Spring is exactly better than Java EE for you? (and please don't just mention that it's supposedly lightweight, not a container, not an EJB, not an AS, portable to many AS', etc, that has been discussed enough already ;) )

I look to Spring first because that way i am not locked to a super expensive, proprietary, J2EE container.

Hopefully this statement is intentionally ironic, but in case it isn't, here are a few corrections:
"super expensive" - take your pick of Glassfish, JBoss, Geronimo, and probably several others - all of which can be had for free.
"proprietary" - I don't think this word means what you think it means. In fact, Spring is obviously the proprietary technology while Java EE is an open, standard specification. If you pick Spring, you get Spring. If you pick Java EE, you're free to choose an implementation/vendor that you like.
"J2EE container" - 1.4 was the last J2EE spec. It's been Java EE for several years now. If it's the "container" that bothers you, then you won't like Spring very much. The main difference is that with Java EE, your app server provides the container, while with Spring, your application provides the container - in the form of Spring jars and configuration.
As for being locked in: can you honestly say that using a proprietary, single vendor solution (Spring) avoids the lock-in you'd experience by writing to an open spec with multiple competing implementations (Java EE)? Seriously?

sorry, forgot the word bloated. I can run my Spring app on Tomcat. can i use J2EE or JEE or whatever you call it nowadays, and my app on Tomcat? Not unless i do not use the JEE parts.
I do not call a single vendor controlled spec "Open". Does Oracle not have ultimate voting rights on specs?
By locked in, i mean i can run my app on _any_ app sever or even light weight containers like Tomcat and Jetty while still having 90% of the capabilities of the bloated JEE specs.

sorry, forgot the word bloated. I can run my Spring app on Tomcat. can i use J2EE or JEE or whatever you call it nowadays, and my app on Tomcat? Not unless i do not use the JEE parts.

Can you run your Spring app on Tomcat? Not unless you include the Spring libraries. Seeing how ignorant you are, this may come as a surprise to you, but let me break it for you:
Tomcat does not run Spring applications out of the boxThe Spring libraries together are already larger than most Java EE implementations (150MB+)Tomcat does not come with a JPA and JTA implementation. You need to add those. Extra libs, extra complexity, extra maintenance
You are ***exactly*** the kind of ignorant Spring fanatic that the Java EE user base starts revolting against. It's not Juergen Hoeller and it's not the quality of Spring, but it's the lunatic fan base. Maybe I just shouldn't feed the troll, but this example is just too much to be left unanswered.
You keep trying to let people believe that Java EE is closed source, monolithic, expensive, commercial vendor based, bloated, heavyweight, etc. And at the same time you seem to be completely oblivious to the fact that the additional jars needed to run your Spring application on Tomcat add up to be more then a typical complete Java EE implementation. You keep spreading the nonsense that your technology stack is supposedly lightweight, "since it runs on Tomcat and tomcat is lightweight" This is just *so* stupid that I barely have words for it...
Java EE is completely open source, free, doesn't cost you a dime other than your download time and is developed and supported by numerous open source parties, including those that also bring you your beloved Tomcat.
And I repeat again. A bare Tomcat does NOT run Spring applications. When you add all those Spring libs and libs for transactions and ORM (which most people using Spring use), the result IS NOT lightweight anymore. You don't even have to mention Tomcat there, since it has become nothing more than a tiny small cog somewhere in the massive frankenstein machinery you have created.

By locked in, i mean i can run my app on _any_ app sever or even light weight containers like Tomcat and Jetty while still having 90% of the capabilities of the bloated JEE specs.

No that's not the idea. No matter what you deploy on, there's *always* the Spring container that's needed and this Spring container is implemented by one single commercial vendor called Springsource.
With Java EE, I can write an application that runs on Jboss AS. When for some reason I decide I don't want to have anything to do with Jboss anymore, I can run my app on Glassfish. When I do so, I *don't* have to drag any Jboss lib along. I don't have to depend on any Jboss artifact.
I understand this may be difficult for you to grasp, but THAT is what is meant with true portability.
You with your Spring application *always* have to drag the Spring libs along. Whether you're deploying on Jboss, Tomcat, Jetty... there is no way around that. Nobody else implements those libs...
Captcha: "Relaxing her" (is this thing artificial intelligent orso? :P)

Can you run your Spring app on Tomcat? Not unless you include the Spring libraries.

Can i run a JEE app on Tomcat by including JEE libraries, no. Seeing how ignorant you JEE people are as you find it necessary to carpet bomb a Spring Release thread with your propaganda, let me break it for you:
J2EE, JEE, etc... was only created by Sun to monetize Java.
The vast majority of projects out there are simple web applications. There is ZERO need for the full bloat of JEE and the requirement for a bloated JEE Server to do this.
Spring let's one pick and choose what you need and deploy on a lightweight container such as Jetty, Tomcat, Resin, etc... I package my entire app up as a WAR and can deploy said WAR on _any_ container, from lightweight containers such as Tomcat, Jetty, Resin, etc... to full heavyweight JEE containers like Weblogic, JBoss, WebSphere, etc...
JEE should be like Spring...if all i need is persistance, i should be able to use only that and package the needed jars in my app(no dependency on the container other than for the Java runtime. Then perhaps more people would use it and you would not need to carpet bomb Spring release notes?

Sure you can. The result is called Geronimo or Jboss... would you want to? That's a whole other question. Tomcat is just a small part in the equation. Taken to the extreme, you could just as well ask whether one can run a Java SE application on java.util.HashMap? Well, you can, if you add all other classes of the Java SE library.
More seriously, the overwhelming majority of the Java EE libs also has separate implementations. JSF (Mojarra, MyFaces), JPA (Hibernate, TopLink), JTA (JoTM), EJB (OpenEJB), CDI (Weld), JMS (ActiveMQ), you name it and there's a separate implementation available.
Now would you *want* to assemble your own stack from all these various sources? It depends... some people might want to do that, and then the option is there. Some people also build their Linux from scratch. The majority of the people simply install Ubuntu and upgrade their entire OS in one go every 6 months.

J2EE, JEE, etc... was only created by Sun to monetize Java.

And you *really* think Springsource is in the game without any objective and without any intent to make a single buck out of Spring?

The vast majority of projects out there are simple web applications. There is ZERO need for the full bloat of JEE and the requirement for a bloated JEE Server to do this.

Here you again, and again and again... did you even read what I wrote above?
If there is ZERO need for the supposedly full bloat of Java EE, then there is LESS THAN ZERO need for the even larger bloat that Spring brings to the table.
If and only if your application is SO childishly simple that you do not need ORM and transactions, nor any MVC, then you simply write that app using the Servlet API and JSP plus maybe JSTL only. There are a few apps like that. I have a local sandwich shop around the corner that has a 3 page web site showing their menu and a simple form to subscribe to their newsletter. A pure Servlet/JSP app is probably all they need indeed.
Many other web application, even the simple crud based ones, at least need a little MVC for e.g. easy validation of inputs and need some transactional support to ensure that in the face of exceptions there is no inconsistent state in the DB (like an order that is partially persisted).
So, then you either use Spring or Java EE. In both cases the added complexity to your application stack is comparable. Spring is typically a little larger than Java EE (150MB+ vs 65MB+) and a little more heavyweight, but when looking at it from a large scale they are approximately the same. Whether you use Spring or Java EE doesn't matter, but in both cases you can't state that you have an incredible simple application that doesn't need anything.
In case of a Tomcat application, that uses nothing but Java SE libs, Servlet and JSP, the mental complexity explodes pretty fast when the app grows. Maintaining all those separate connections is hellish. If you have the guts to use JDBD resource local transactions, you have to manually propagate your connection to all involved code, which means storing the connection somewhere global (like in TLS, or in request scope), or passing it along. Whatever you think of, it simply doesn't scale. Your code becomes one huge lumb of spaghetti and development grinds to a halt.
Enter Java EE...
You take a POJO... apply 1 single simple annotation to it... and voila! Completely managed and incredibly simple transactional support.
Where's the bloat you're talking about? Let me tell you where it is... It's simply not there! It's not the 65MB on your HDD, that's completely peanuts by now. People have HDDs in the terabyte range now. There's also no API overhead or mental complexity. It just *1* annotation. The supposedly simple JDBC uses 4 statements alone to do the most simple DB operation imaginable. If you want to use the resource local transactions, you need to add several more statements.
So tell me, please... where is this bloat of yours since I sure as hell ain't seeing it pal.

Spring let's one pick and choose what you need and deploy on a lightweight container such as Jetty, Tomcat, Resin, etc... I package my entire app up as a WAR and can deploy said WAR on _any_ container, from lightweight containers such as Tomcat, Jetty, Resin, etc...

Wow, do you really even read what I wrote? What's in that war you're deploying? Not Spring libs right? Otherwise it aint such lighweight anymore mister. I what about this silly emphases on _any_ container? Again, did you read what I wrote???
How about using _any_ Spring implementation?
That's not possible right? There is only *one* Spring implementation!
You might as well have added that next to deploying to any container, you were able to deploy to any JVM on any operating system, but that's not what this discussion is about. We're talking about the Java EE APIs vs the Spring APIs.
I can deploy my Java EE app (.war or .ear) on ANY Java EE implementation, and my .war is much smaller since I don't go packing XXMB of jar files along.

.if all i need is persistance, i should be able to use only that and package the needed jars in my app(no dependency on the container other than for the Java runtime.

What's your next suggestion? Packaging all libs from the Java SE runtime along? Do you package along your own java.util.HashMap? Your own java.lang.String?
You don't need to package along stuff that's in the standard libraries. Period.
Next to that, all modern Java EE implementations are very modular. In Jboss I can already choose from different profiles when starting up the server (minimal, web, default, all). Glassfish is almost even more flexible here.In the end it's WAY easier to deactive things I don't need then to actively go hunt different websites and download stuff of which I forget their origin afterwards and which may or may not work with the stuff I already package along.

So, then you either use Spring or Java EE. In both cases the added complexity to your application stack is comparable. Spring is typically a little larger than Java EE (150MB+ vs 65MB+) and a little more heavyweight, but when looking at it from a large scale they are approximately the same. Whether you use Spring or Java EE doesn't matter, but in both cases you can't state that you have an incredible simple application that doesn't need anything.

Just a minor correction:
Spring JARs measure up a whole 4.5 MB (not 150 MB), which means it is about 14 times smaller then reported JEE distribution. (check 'dist' folder of Spring distribution)
Spring distribution comes in 20 modules where two of them are for testing support and never included with distribution of your app. You only need to include the modules your application needs which is on average 10-12 modules for a typical application (~ 2MB)

Third party jars with Spring are 40M. Jars shipped with Glassfish I just downloaded are ~40M as well. Are you considering Spring as IoC container only or what?

Chief, I explained the story behind the third-party jars above. It has been well understood for years that those are optional dependencies that we need for compiling and testing, and not mandatory dependencies at runtime. And FWIW, we are not shipping them with Spring 3.0 anymore: So there are only 4.4 MB of core Spring jar files in the entire 3.0 distribution. Nothing to get confused by anymore. Again, as mentioned above, a typical Spring app will include a persistence provider and possibly one or two further libraries, but hardly more than 15-20 MB of jars overall.
Augustientje, it's utterly disingenuous to compare zip download sizes and to take that enourmous amount of docs and convenience dependencies into the count without closer consideration. This is not comparable to the GlassFish distribution at all, which contains minimal docs only. Shall we start adding all of Sun's general Java EE 6 documentation to that GlassFish distribution size? I'm sure that's easily a couple of hundred MBs. After all, you'll "conceptually have to wade through" all of Java EE 6 when using GlassFish, according to your line of argument?
Please re-read my post above where I explained the practical situation with actual use of Spring, in case you really don't know yet. If you'd like to compare sizes, then compare runtime jar sizes. Download sizes mean nothing at all, in particular since most Spring users are getting Spring through Maven these days where they literally only obtain the binary jars - less than 5 MB. Even including all the other Spring libs that you added, you'd still be at less than 10 MB. And including Hibernate and Tomcat, it'll still be no more than 20 MB. Whereas GlassFish has 140 MB of jars...
Juergen

it's utterly disingenuous to compare zip download sizes and to take that enourmous amount of docs and convenience dependencies into the count without closer consideration. This is not comparable to the GlassFish distribution at all, which contains minimal docs only

Juergen, I know comparing download sizes is a little silly. I was only trying to debunk the pervasive claim uttered by some lunatic Spring fanatics that a Spring application runs on a bare 6.1 MB Tomcat, without needing anything else. Using the MB figures, one can prove whatever one likes. I showed that the download size of Spring is a good deal larger than one particular Java EE implementation (Glassfish). Someone else could have been smart and point out that the Websphere download size is even larger, or the Jboss download size is about equal to that. What do we actually win with this argument? Not much as far as I can see.
Then the run-time argument. People have to copy jar files from the distribution they downloaded to their WEB-INF/lib directory. If you know what you're doing, you can keep the size fairly moderate. Unfortunately, not all people really know what they are doing. When doing consultancy I've more than once encountered deployments where people just downloaded all the necessary archives (the multiple Spring downloads, Hibernate, etc) and copied all jar files they encountered to their project, totally oblivious of the difference between compile time and run time libraries. These war files really were in the 100MB range. This happened not once, but multiple times.
But even if you trim the required Spring libraries down to a moderate size. What does this really mean? Suppose I didn't also trimmed Glassfish and compared a 33MB Spring based war running on a 6.1MB Tomcat with a ~70MB Glassfish? Are those extra 37MB on your HDD really what makes the difference? Has anyone ever chosen say Redhat over Debian, because when installed Redhat takes up 37MB less HDD space than a default install of Debian? I can't imagine that in this time and day anyone in their right mind would actually ponder about that for more than a single second.
There are more things to consider though.
One of our smaller enterprise applications that I just looked up, consists of approximately 150K lines of custom Java code and another 50K lines of code in other files (mostly facelets XHTML files, but there's some other stuff there). The size of the .ear is no more than 4.1 MB. This is because this particular application doesn't require any other lib than what's already in Java EE and Java SE. We don't have to include Hibernate, JSF, a transaction manager... no nothing... If I compare this to some 'lightweight' Spring war files, which weigh in at a minimum of 10 MB, but are more often in the 20 ~ 30 MB and beyond range, then again Java EE is a winner here.
It doesn't stop there though...
Apparently unbeknownst to many Spring users, Java EE implementations can also be trimmed. For instance, the Jboss AS client directory contains 25.6 MB of jar files, which are intended to be copied to a client that wishes to connect to a Jboss AS instance. These jars are just part of the download archive and have zero run time overhead. If you're anal about your HDD footprint, you can immediately delete this dir after the download. To continue the fun, the Jboss AS archive contains a couple of pre-assembled configurations, among which is the server/all config. This contains 35.3 MB and can be immediately deleted if you want. Jboss AS starts up using the server/default configuration and server/all is just for your convenience. Another 16.6 and 7.1 MB can be lost by deleting the server/standaard and server/web configurations. Eventually, a trimmed down Jboss AS can be around 30 ~ 40 MB, and even much less if you would only run Servlets and JSP.
How is that really different from a nearly 200 MB download of various Spring archives, where you eventually also only copy a selection from?
But hang on, there is still more to come...
Download size or run-time size are within certain bounds largely irrelevant. I've argued this point a couple of times. The only reason why I elaborate about this, is because Spring fanatics try to use it as a weapon against Java EE. Unfortunately for them, they by far don't see the whole picture, so they are 'defeated' by their own weapons.
What really matters is the mental complexity of the programming model of course. As a final point in this discussion, we all know that J2EE 1.3 is our mutual enemy that started this whole feud between various fractions of developers. J2EE 1.3 is the prime example of extreme bloat. It contains the downright evil EJB 2.0, which forced us to maintain impossible to comprehend overly and needlessly verbose XML deployment descriptors, with a massive amount of senseless methods from interfaces that developers where forced to implement for the simplest of things. Anyway, I don't have to explain this to the Spring crowd. Rod has literally brought you up with that.
Yet, let's take a J2EE 1.3 implementation, one that you can actually still download to this day:
orion2.0.7.zip 6.8 MB
Yes folks, you read that right. This is no typo. Orion 2.0.7 weighs in at only 6.8 MB, basically the exact same size as Tomcat. This includes Servlet, JSP, EJB, JTA... the whole shebang. Startup time is beneath a second (just like Tomcat) and JSPs are compiled instantly (way faster than Tomcat). Yet, *this* is the bloated J2EE 1.3 platform that Spring thanks its very existence upon. ---> 6.8 MB <---
Please... please don't bring up the MB size again in this discussion. It's a nearly completely meaningless figure for this discussion.

Please... please don't bring up the MB size again in this discussion. It's a nearly completely meaningless figure for this discussion.

No offense, but you were the one who brought it up in Message #330829.

That's a good observation ;) There is a bit of a history here of course. The MB size is a very, very common argument when Spring fanatics refer to Java EE being bloated. In #330821, the same line of argumentation started again that we have seen during all the previous years.
I'm becoming so battle-hardened in this discussion that I automatically thought a step ahead. The MB argument was undoubtedly about to be used ;) There simply never has been given another answer to what exactly constitutes this alleged bloat in Java EE, just read back the plethora of old Spring vs Java EE discussions on tss and other sources.
Yet, I confess that I made a basic discussion error here. What can I say, "He who is without sin among you, let him throw the first stone" ;)

"People have to copy jar files from the distribution they downloaded to their WEB-INF/lib directory"
. . .
" If I compare this to some 'lightweight' Spring war files, which weigh in at a minimum of 10 MB, but are more often in the 20 ~ 30 MB and beyond range, then again Java EE is a winner here"

Not true again
Your argument is based on the fact that on the GF or JBoss etc... all the necessary JARs are part of AS itself and you can deploy multiple apps reusing the same libraries. Well you can do the same on TC by putting these required JARs in the TC_HOME/lib directory, thus keeping your WAR/EAR size very small (nothing in WEB-INF/lib)

"Unfortunately, not all people really know what they are doing."

So your remedy (if I understand it correctly) to keep those people stupid and prescribe them a platform which supposedly will take care of everything? I alway thought that the job of a senior engineer/developer is to educate and mentor others and point out common mistakes and anti-patterns (even if they come from self-proclaimed EG), but then again it might just be me ;)

"How is that really different from a nearly 200 MB download of various Spring archives"

As Keith pointed out, you are the one who brought the argument. . . we are just responding. It is also funny how you brought JBoss into discussion. . . no one on this thread questioned JBoss and its capabilities, so what does it have to do with the original topic of this thread which is Spring 3.0 GA release ;)

"Please... please don't bring up the MB size again in this discussion. It's a nearly completely meaningless figure for this discussion. "

Again, you brought it up, you keep talking about it as if it is relevant, but right after saying that it is not and asking people to stop? How about drinking your own cool-aide ;)

"so they are 'defeated' by their own weapons."

The bottom line is, this thread is about Spring 3.0 GA release, mainly to discuss issues, concerns, suggestions etc. . . unfortunately you and few others keep making an attempt to hijack it and make it look like we are back in JEE vs Spring war. This thread is not about JEE, GF, JBoss, CDI etc... there is one already http://www.theserverside.com/news/thread.tss?thread_id=58858

Your argument is based on the fact that on the GF or JBoss etc... all the necessary JARs are part of AS itself and you can deploy multiple apps reusing the same libraries. Well you can do the same on TC by putting these required JARs in the TC_HOME/lib directory, thus keeping your WAR/EAR size very small (nothing in WEB-INF/lib)

Sure you can do that. Absolutely so even. But then you've build yourself something that is very close, sometimes near identical to what Glassfish or Jboss, etc actually is. That is my point the whole time really. Internally, Jboss really is Tomcat + a bunch of jars in a way. If you want you can add the majority of these jars yourself to a bare Tomcat and then only deploy a very small .war file, just like you would do with a Java EE implementation.
You can even also do it the other way around. Enable scoped classloading or classloading isolation in your AS, and package along your own Hibernate and JSF libs. This would probably not be needed very often, but theoretically the option is there.

So your remedy (if I understand it correctly) to keep those people stupid and prescribe them a platform which supposedly will take care of everything?

Absolutely not. I've said nothing of the sort. I only mentioned that I observed this behavior. It doesn't make sense to convert people to Java EE when you're in for a consulting job and their entire stack is Spring based. I would be out of my mind (and probably out of a job) if I attempted that. Of course I point people to their mistakes and even teach them to use a jar analyzer (like tattletale) to find the jars they're needlessly deploying.
But then I enter into the next consulting job and I encounter the same situation again. And a few jobs later, again... etc. It's certainly not that everyone is doing this all the time, but I've seen it multiple times.

It is also funny how you brought JBoss into discussion. . . no one on this thread questioned JBoss and its capabilities

Jboss AS was just used as an example, nothing more. All of this was in reply to the original poster who felt the need to mindlessly bash Java EE by calling it bloated and proclaiming that Spring is better since you can deploy it on lightweight Tomcat. This entire line of discussion is just to point out there is no 'lightweight' Tomcat when you use the typical Spring based stack. You either add the additional jars to your .war or as you pointed out directly to Tomcat, but either way the extra jars are there and their complexity roughly equals what Java EE brings to the table.
Since there is no single "Java EE", I just happened to took Jboss AS as a representative example for Java EE. It's an implementation of it after all. I could also have used Glassfish as an example or Geronimo and that would have worked just as well.

Again, you brought it up, you keep talking about it as if it is relevant, but right after saying that it is not and asking people to stop? How about drinking your own cool-aide ;

I did apologize for the seemingly inconsistent reasoning, didn't I? ;) But I also explained why I did it. The original post was about Java EE supposedly being bloated. How does one measure bloat? It always comes down to the number of MB really. Every time I ask those fanatics why they think Java EE is bloated, they first start some circular argument and then eventually the MB argument is raised as 'proof' that Java EE is more bloated than Spring. I just wanted to short circuit that silly argument as soon as possible. I realize it looked inconsistent, I raised the MB argument and then I ask people not to use it, but it wasn't meant that way.
Anyway, I still haven't gotten an answer from this original poster where this supposed bloat in Java EE then exactly is, and where this supposed lightweigtness in Spring exactly is. I'm sure, really sure, that this original poster was going to reply again that it is because Spring apps can be deployed on the *small* lightweight Tomcat, so just to cut that discussion off real soon I explained ahead of time that this 'smallness' is irrelevant and that I'm *not* accepting that as an answer.

The bottom line is, this thread is about Spring 3.0 GA release, mainly to discuss issues, concerns, suggestions etc. . . unfortunately you and few others keep making an attempt to hijack it

You know, you are right about that and I actually feel bad for doing this. It is what Spring fanatics have been doing with every single Java EE related news item though. You can place a bet on it that every time Java EE or EJB is mentioned, some Spring fanatic will post a reply along the lines of "Is this still relevant? EJB has been buried a long time ago. Use Spring!!!". Sometimes it actually works to give one a taste of their own medicine, but then again, maybe we should not fight fire with fire, especially not in this time of the year where we should be celebrating with our beloved ones ;)

Spring JARs measure up a whole 4.5 MB (not 150 MB), which means it is about 14 times smaller then reported JEE distribution.

Well, those 'Reported Java EE distributions' also contain docs and client-side libs that your application probably never needs. Just as with Spring, you can delete the docs, not read them, whatever.
But let's play this little game along...
From the Spring download page:
spring-framework-3.0.0.RELEASE-with-docs.zip (sha1) 44.5 MB
spring-framework-3.0.0.RELEASE.zip (sha1) 21.2 MB
spring-webflow-2.0.8.RELEASE-with-dependencies.zip (sha1) 54.6 MB
spring-webflow-2.0.8.RELEASE.zip 10.7 MB
spring-security-3.0.0.RC2.zip (sha1) 17.9 MB
spring-ws-1.5.8-with-dependencies.zip (sha1) 27.9 MB
spring-ws-1.5.8-minimal.zip (sha1) 1.3 MB
That's 144.9 MB already.
Now maybe ws dependencies and webflow dependencies overlap? Do they? I have no idea really, but if they are dependencies, I need them. The software doesn't run without them.
Now, I STILL need an ORM implementation, and I STILL need a JTA implementation, oh, and of course I also still a Servlet container. Let's take Hibernate, JoTM and Tomcat:
hibernate-distribution-3.3.2.GA-dist.zip 42.8 MB
jotm-2.0.11.MR3.tgz 2.4 MB
apache-tomcat-6.0.20.zip 6.1 MB
So, now I have a reasonably complete environment, the core framework, the web layer MVC, some security, some persistence with transactions, the servlet container and some web services support thrown in for good measure.
Now we're at 196.2 MB.
Agreed, there might be docs there, there might be examples there, but this is what I need to download and this is what I conceptually have to wade through.
Now let's look at Java EE:
glassfish-v3.zip 63 MB
That's it...
63 MB and I have *everything*. Web framework, security, persistence, transactions, web services, serlet container... everything...
Now I might not need everything in that 63 MB, but big deal... I can simply remove those few pieces I don't need if I'm really anal about imagined complexity. It really is a moot point, since Glassfish doesn't load what you don't use.
With Spring I had to do 7 different downloads, maybe 6 if I don't need webservices, but still. Then I have to wade through the archives anyway to remove or ignore stuff that I supposedly don't need. Maybe I decide upfront I don't need documentation for the core, well that brings me down only some 20 MB.
No matter how you put it, it's VERY hard to match Java EE's 63 MB.
Of course, I must stress that this little game of who has the largest download size is largely irrelevant. My HDD is in the terabyte range. Low-end users have HDDs in the hundreds of gigabytes range. Users and certainly companies don't care whether a distribution is 100, 200 or 300MB. Java EE wins here, but I don't care that it wins here. My only point is that Spring fanatics somehow dare to insist that a Spring application runs completely on a 6.1 MB Tomcat and needs nothing else besides their own code. This is simply not true.
But again, this entire line of reasoning is just silly. Java EE and Spring are more or less in the same ballpark here.

I work on a fairly average-sized Spring/Tomcat application. The application uses an Oracle database of ~180 tables totalling about 3 billion rows. Not the biggest app but not trivial either.
The app uses a variety of JARs with total size about 32MB. The Spring ones, which include most of the "core" Spring modules as well as some of spring-ws and spring-security, total about 5MB. Pretty reasonable.
Regards
John Hurst
Wellington, New Zealand

that's crazy. you've just described my 33mb application with a million lines of custom written code as requiring 144mb. And of those 33mb, the largest jar is the oracle jdbc driver.
and what's funny to me is that i don't actually like spring that much. but java ee is just soooo much more annoying.

It's funny how the perennial "Spring vs. JEE" debate always ends with tables summarizing Spring ZIP sizes...
And while I'm here, I have to present one example. Our J(then 2)EE application started using "Spring" in 2004. It was 1.0.x version. Now it's using 3.0.0 and the only file we had to modify was one property file, where "class" had to be changed into "(class)". That's what I call ROI. Can you tell the same about JavaEE?
At the same time this application was stripped off MDBs (which were replaced with Spring's (== JSE 5) task executors) and container managed security (Spring Security). Now it's WAR application which runs on Tomcat/Jetty and starts in 25 secs. (WebSphere - 2 minutes).
The ROI is where nothing has to be changed. But at the same time our application was more and more maintanable (thanks to e.g. Maven), simple and "transparent" - we have full confidence in Spring - we have the code.
I know - JavaEE specs are "well thought", clear and publicly available. So are TCKs (do they? ask Apache). But what about the sentences in some specs - "the implementation details/this scenario/this behaviour is implementation dependent"). We don't believe in myths - we can't "change the app server when we no longer want to deal with JBoss/Glassfish/WebSphere". We choose Spring (source code and Maven JARs) lock-in because it's worth it.
I'm not saying which is better. I just have a feeling that this debate reflects similar debate from the time when SpringSource has announced new "licence policy" and lot of developers declared that Spring is dead, long live Google Guice. Now Spring is (once again) dead, long live CDI RI (a.k.a. Weld).
Back to topic - congratulations on Spring Framework 3.0.0 release! I just can't wait to see SpringSecurity 3.0.0 and Spring Integration 2.0.0!
For me it's ridiculous to read "Spring vs. JavaEE". Spring IS JavaEE where it's worth it. DI is part of JavaEE since ... 2 weeks and comparing Weld (which has some good features just as Guice has) to "Spring" (whole framework? WS? Integration? Security?) is like ... you know what.
regards
Grzegorz Grzybek

If and only if your application is SO childishly simple that you do not need ORM and transactions, nor any MVC, then you simply write that app using the Servlet API and JSP plus maybe JSTL only.

Or i can simply use Spring with a couple of annotations and have full transaction management. And i can use GWT which is far superior to the horrid JSTL and JSP debacle. Best yet, i can make a simple war file, and deploy to Jetty and have a highly scalable lightweight app which i can deploy on _any_ java container unlike a bloated J2EE app.

With Java EE, I can write an application that runs on Jboss AS. When for some reason I decide I don't want to have anything to do with Jboss anymore, I can run my app on Glassfish. When I do so, I *don't* have to drag any Jboss lib along. I don't have to depend on any Jboss artifact.

Hey great. Can you take it to Tomcat, Jetty, or Resin? Nope. I can take my Spring + GWT app there or even to your bloated JEE servers. I understand this may be difficult for you to grasp, but THAT is what is meant with true portability. JEE does not offer true portability.
Many other web application, even the simple crud based ones, at least need a little MVC for e.g. easy validation of inputs and need some transactional support to ensure that in the face of exceptions there is no inconsistent state in the DB (like an order that is partially persisted).
So, then you either use Spring or Java EE. In both cases the added complexity to your application stack is comparable. Spring is typically a little larger than Java EE (150MB+ vs 65MB+) and a little more heavyweight, but when looking at it from a large scale they are approximately the same. Whether you use Spring or Java EE doesn't matter, but in both cases you can't state that you have an incredible simple application that doesn't need anything.

In case of a Tomcat application, that uses nothing but Java SE libs, Servlet and JSP, the mental complexity explodes pretty fast when the app grows. Maintaining all those separate connections is hellish. If you have the guts to use JDBD resource local transactions, you have to manually propagate your connection to all involved code, which means storing the connection somewhere global (like in TLS, or in request scope), or passing it along. Whatever you think of, it simply doesn't scale. Your code becomes one huge lumb of spaghetti and development grinds to a halt.

Wow. So you basically have no clue what you are talking about. Have you ever even looked at how spring manages transactions? Hint...JEE copied it. I declare transaction support with a single annotation on the method.
JSP is garbage and totally bad. Who in their right mind would use that stuff when there are far superior technologies around like GWT or Tapestry?
J2EE is dead. JEE was born out of its total failure and is DOA. Still complex, still bloated, still vendor driven rather than developer driven. The Java world has moved on....

Or i can simply use Spring with a couple of annotations and have full transaction management.

Sure you can, as I explained above you can use either Java EE or Spring then. Do you actually read what I post? Or am I talking to an automated script that is triggered on some keywords and provides an automatic response?
Just to test this hypotheses, could you (seriously) reply to this:
"If I have two apples, and eat one of those, how many apples do I still have?"
Please answer this, I really would like to know whether you're human.

Best yet, i can make a simple war file, and deploy to Jetty and have a highly scalable lightweight app which i can deploy on _any_ java container unlike a bloated J2EE app.

There you go again... the same words... Tomcat is lightweight... Jetty is lightweight.... J2EE... bloated...
Could you *try* to actually say something intelligent? For starters, explain to me why Java EE is bloated? What is bloated in Java EE? It's not the download size as we have established above. It's not the complexity of the API, as I also explained above. Yet you keep chanting like a drunk "J2EE... bloated! J2EE... bloated"
And stop that nonsense about _any_ container. As was said before, I can also deploy my Java EE app to any AS (Jboss, Geronimo, Glassfish, Wehsphere, Weblogic, JOnAS, ...) and when I do that I don't have to drag any technology that I don't want to use anymore along.

Hey great. Can you take it to Tomcat, Jetty, or Resin? Nope. I can take my Spring + GWT app there or even to your bloated JEE servers. I understand this may be difficult for you to grasp, but THAT is what is meant with true portability. JEE does not offer true portability.

It does, but you don't see it. You have to drag your libs along. Tell you what...
I can take my Java EE app, completely with Jboss AS included TO ANY JVM! HA! How you like that! That's true portability huh? My app simply includes Jboss AS, just as your app includes Spring. Apples to Apples comparisons here.
I can deploy my app to the Sun JVM, to the IBM JVM and to the Apache JVM. Those are the ultimate in lightweight! No need for a bloated Tomcat, Jetty or Resin to be present. All I need is a JVM! Yippy Kaye! Taleladie lo! :P

Wow. So you basically have no clue what you are talking about. Have you ever even looked at how spring manages transactions? Hint...JEE copied it. I declare transaction support with a single annotation on the method.

In Java EE I don't even need a single annotation on the method, session bean methods are automatically transactional. Plus, how can Spring copy it from Java EE, when Java EE was first with introducing annotations? Spring used XML for everything remember, and when Java EE introduced the lightweight model of using user friendly annotations, Spring copied that.
But it's not about being first, it's about what's there now. As I explained time and again, but which you seem to be unable to comprehend; Java EE and Spring are in the same ballpark. You can't use Java EE and claim that Spring is a 'totally' wrong and bloated affair, nor can you make that claim the other way around.
Furthermore, Spring doesn't implement a transaction manager. It builds on JTA and JDBC. Now my friend, tell me, where do these two APIs originate from? Right! Who's the one without clue now huh?

JSP is garbage and totally bad. Who in their right mind would use that stuff when there are far superior technologies around.

For once I agree with you, and that's why everyone of course uses the far superior Facelets, which happens to be made the default in Java EE 6.

J2EE is dead.

And had been for a long time. Why on earth do you keep bringing it up? We also aren't talking about Spring 1.x, are we?

JEE was born out of its total failure and is DOA. Still complex, still bloated, still vendor driven rather than developer driven. The Java world has moved on...

Would you just like me to copy paste the older replies over and over again? What is this bloat that you keep referring to? I only see an extremely easy and lightweight programming model. Interns and students grasp it within minutes. But AGAIN... give me an example of this supposed bloat and PLEASE don't go babbling again that it's bloated because you can't deploy on Tomcat. That's not the definition of bloat. And please also don't start telling me that it's bloated because it isn't lightweight. That's the circular line of reasoning dumb Spring fanatics have been using for years. It has zero substance and doesn't explain a thing. "J2EE is bad, because it's bloated. It's bloated because it's a container. A container is not lightweight. Spring is lightweight. What is lightweight? Spring is lightweight. Bla bla bla...". Can't you see that it doesn't explain a thing? (don't answer that, I know you can't).
You Spring fans had your fun with this nonsense in 2004, but for the love of god man, drag yourself into the present. Look at some calendar, it's NOT 2004 anymore...
And please, pretty please, stop that vendor driven nonsense. Springsource is just as much a vendor as Jboss is. Java EE has implementations from various open source parties, including Apache. AGAIN, Java EE is completely open source, made by developers, for developers. It's completely free to download, etc etc.

Actually, Caucho are in the process of implementing the EE 6 web profile as a built-in feature of Resin. So in the case of Resin, the answer is yes.
And as pointed out to you, there are Java EE implementations that use Tomcat and Jetty as the web container. So the answer is yes in those cases also.

Have you ever even looked at how spring manages transactions? Hint...JEE copied it. I declare transaction support with a single annotation on the method.

ROFL! I'm sorry, but no :-)
Actually, declarative transaction management goes back at least as far as Microsoft's MTS. This facility was copied first by EJB, and then by Spring. The use of annotations for transaction management was introduced first by .Net, then by EJB 3.0, and finally copied by Spring.
You really have it backwards on this :-)

JSP is garbage and totally bad.

Agreed. That's why EE 6 introduces facelets as a standard feature. But what's your point? All servlet engines include JSP built-in. So how is this a point of difference b/w Spring and EE6?

J2EE is dead.

I think we can *all* agree, on the basis of the huge interest in the EE 6 release, that this is definitely *not* true :-)

The Spring libraries together are already larger than most Java EE implementations (150MB+)

Where does this 150 MB number come from?? Definitely not from the Spring libraries...
Let's talk facts: We were shipping a lib directory containing 42 MB with Spring 2.5.6. However, 99% of the jars there are optional libraries that we integrate with and that we run our test suite against. After all, nobody is using 3 different JPA providers in the same app, and nobody is using 3 different scripting languages or 3 different web service engines either. The only mandatory dependency is commons-logging with a couple of KB. This is well understood by Spring users; we are not getting much complaint there.
The actual Spring framework jars add up to a grand total of *3.6 MB* in 2.5.6, and *4.4 MB* in 3.0 GA. That's the actual size of the framework and all of its optional parts already: about the same size as the Groovy 1.7 runtime, not much larger than Hibernate 3.5, and significantly smaller than EclipseLink 2.0, for a few reference points. It's also a bit smaller than the Tomcat 6.0 jar directory which adds up to 4.7 MB. For a sharp contrast, GlassFish and JBoss both contain way more than 100 MB of libraries.
Point taken that real-life usage of Spring with a persistence provider etc on Tomcat will add up a bit, but usually to no more than 15-20 MB... which is still pretty lightweight in comparison, I would argue. If you ended up with more than that, then you probably added third-party jars that you are not actually using at runtime. I've seen this often enough myself; in any case, it's easy enough to clean up if it happened.
A side note since you mentioned transactions: Most Spring applications do not use a JTA provider but rather use Spring's built-in support for native transaction management against JDBC, JPA, JMS etc. For that reason, they are not adding a JTA provider to their libs either: the basic persistence provider is all they need. (Of course, when running on an EE server, Spring may just use JTA as provided by the server itself.)
Juergen

sorry, forgot the word bloated. I can run my Spring app on Tomcat. can i use J2EE or JEE or whatever you call it nowadays, and my app on Tomcat? Not unless i do not use the JEE parts.

I do not call a single vendor controlled spec "Open". Does Oracle not have ultimate voting rights on specs?

By locked in, i mean i can run my app on _any_ app sever or even light weight containers like Tomcat and Jetty while still having 90% of the capabilities of the bloated JEE specs.

So, with Java EE, you'd be "locked in" to a choice of at least three free (and several more commercial) competing implementations? Has "locked in" been redefined to mean "can't run on bare servlet container + a bunch of jars that I supply to provide most of the functionality that comes for free with an EE app server"?

My experience shows me that 100% portability between containers is just a myth, just think of containers specific configurations.

Does portability have to be "100% portability" to be useful?
Are you better off if 0% of your code and other artifacts are portable, or if 99% of your code and 85% of other artifacts are portable?
I think you'd have to be nuts to argue that "completely non-portable" is better than "mostly portable".

I'm not sure where the 0% comes from? Are you ref. to non-Java solutions?

I think it refers to among others Spring.
Since there is only 1 Spring you can't, by definition, port a Spring app to another Spring implementation. Don't try to use the "but Spring can be run on both Tomcat and Jetty" argument, since that's not what it's about here.
We're talking about moving an application from 1 Spring environment to another Spring environment, not about moving Spring itself from one servlet container to the other.
If you keep insisting on that nonsense, you might as well say that Java EE is 100% portable, since we can move Jboss AS from the Sun JVM to the IBM JVM. OF COURSE, that is not what this is about.

I'm not sure where the 0% comes from? Are you ref. to non-Java solutions?

No, he is referring to JEE versions. Like, you can not run a JEE6 app on Weblogic 10.3 for example. With Spring, i can run Spring 3.0 on Weblogic 10.3 with no changes other than the container specific files if you are using things like Weblogic JDBC connection pools.

I am not sure this is either here or there as far as portability is concerned, but I'll address the point...
You'll have to upgrade Spring runtime libraries to use a newer version just as you will need to upgrade an app server to use a newer version of Java EE. I think it's pretty subjective which is easier given that maintaining handfuls of jar compatibilities per application isn't necessarily that much simpler than for example installing a fresh app server for a new application...
In fact, most Java shops that I know of are usually on a regular upgrade cycle, so using a newer version of Java EE typically isn't a big practical issue unless you are using a vendor with very slow pace of development such as WebSphere.
Lastly, a vast majority of Java EE APIs, including CDI, JSF, JPA, bean validation and JAX-RS are pluggable so can be used on any app server version. For example, there are numerous people using Seam (which is now a CDI implementation) on WebSphere as an interim solution until their server upgrade cycle catches up.
That all being said, my personal opinion is that compatibility alone is a poor reason to be using Java EE. In my opinion, there are far more solid reasons like usability, features and vendor support that makes Java EE compelling for most adopters.
Finally, if Spring is working for you, great. I don't think anyone is forcing anything else on you. For one, this is a Spring 3.0 thread after all and we should probably be respecting that and minimizing Java EE related discussions unless they are really unavoidable...
Hope it helps,
Reza

One difference between moving to Spring 3 vs moving to an app server that supports JEE 6 is that spring is typically under the control of the development group while the app servers are often times, under the control of a production support group. As a developer, I can just change my maven settings, and down comes the latest spring. I run my tests and with any luck, I'm done. Changing the app server on the other hand, probably involves getting buy in from the production group. These people are usually more interested in maintaining the current stable systems vs taking their chances on something new.
Eric

These people are usually more interested in maintaining the current stable systems vs taking their chances on something new.

I would say you have much bigger organizational issues if you're IT team really doesn't see the value in capitalizing on their IT investments by staying on a regular upgrade cycle. I certainly don't see this to be the case in any of my former clients, not even the stodgy IBM shops, so I am inclined to see this argument as anti-Java EE FUD.
Also, please see my previous point in using pluggable Java EE APIs using something like Seam as an interim solution.
Hope it helps,
Reza

I would say you have much bigger organizational issues if you're IT team really doesn't see the value in capitalizing on their IT investments by staying on a regular upgrade cycle. I certainly don't see this to be the case in any of my former clients, not even the stodgy IBM shops, so I am inclined to see this argument as anti-Java EE FUD.

Let's say I want to upgrade from WebLogic 10x to a new version of WebLogic that supports JEE6. And where I work, prod app servers are managed by a separate group which is different from the development team. These are all the list of things I would have go through before getting an approval:
1. Convince my management that the licensing cost involved with the upgrade is worth it.
2. Work with the Technology Infrastructure team to plan for the new hardware. New hardware is required because we cannot take down the existing systems running on the older version to begin the process of App server upgrade. Application has to be deployed on the new app server version and then we can decommission the old versions.
3. This new hardware brings in a whole lot of bells and whistles along with it. Capacity planning, stress test, load test to name a few...
4. Typically a new version of WebLogic comes with new administration console/features as well..now we will have to train the developers and the operations team to learn the new stuffs.
Guess what I am trying to say is, it is not as simple as saying

capitalizing on their IT investments by staying on a regular upgrade cycle

Atleast not in the place where I am working.
Finally as a personal rant, I guess we should ban this FUD word. It is being abused ;)

No offense, but maybe your place is then simply not such a nice place to work?
I understand that some very critical highly hierarchical organizations have to work like this, but we're not an extremely small company (several millions revenue) and we simply install a new Jboss version every time.
Upgrading Jboss is for us really easier than upgrading the set of separate jar files that we maintain. We're at Jboss AS 5.1 now.
Oh, and we also upgrade the JVM periodically. We're at Java 6 update 14 now.

No offense, but maybe your place is then simply not such a nice place to work?

Oh, it absolutely is a great place to work. Otherwise I wouldn't be here.

I understand that some very critical highly hierarchical organizations have to work like this, but we're not an extremely small company (several millions revenue) and we simply install a new Jboss version every time.

I am wondering whether you would be upgrading every time if your organization has gone with WebLogic or WebSphere or any other commercial product. Pretty much you are stuck with JBoss or Glassfish. What are the other options?
Just curious, assuming your app is supposed to be up 24*7: When you install new version of JBoss every time, what are the steps to transition from one version to another?

Upgrading Jboss is for us really easier than upgrading the set of separate jar files that we maintain. We're at Jboss AS 5.1 now.

I am not sure if I follow this. You mean upgrading commons-lang jar from version x to y is more difficult than upgrading your app server?

I am wondering whether you would be upgrading every time if your organization has gone with WebLogic or WebSphere or any other commercial product.

Again, I think you are overemphasizing this way too much or things in your company are really that complicated/stodgy. Firstly, it's not like most app servers are really released that frequently. In case of most commercial application servers we are talking about an endeavor maybe once every other year - not a big deal by any stretch of the imagination since most upgrades are done off hours and with HA environments in play with load-balancing/clustering to make the upgrade process fairly smooth.

You mean upgrading commons-lang jar from version x to y is more difficult than upgrading your app server?

This is another red herring argument IMO. The point here is that it is not hard to upgrade a single jar, but it is not so trivial to keep things straight for multitudes of inter-related jars across multitudes of applications. In case of an app server upgrade, the changes are far more atomic since you are upgrading the entire runtime in one go. See the point now?
As I've mentioned more than once now, you can also simply use something like Seam 3 as an interim solution which gives you near complete Java EE 6 functionality if things are really that bad for you in terms of app server upgrades. That's certainly what I see a lot of WebSphere folks doing, for example.
Cheers,
Reza

As I've mentioned more than once now, you can also simply use something like Seam 3 as an interim solution which gives you near complete Java EE 6 functionality if things are really that bad for you in terms of app server upgrades. That's certainly what I see a lot of WebSphere folks doing, for example.

Cheers,Reza

Well, Seam 3 doesn't exist yet. It doesn't even have an alpha/milestone out - it's just being talked about when trying to promote CDI. What you are possibly seeing some WebSphere folks doing is using Seam *2* which of course gives them no Java EE 6 functionality whatsoever.
That aside: "near complete Java EE 6 functionality" when there is no EJB 3.1, no Servlet 3.0, no JPA 2.0, no JSF 2.0 - since all of those would require core server updates when running on an EE 5 server which has baked-in EJB 3.0, Servlet 2.5, JPA 1.0, JSF 1.2 where you can't even upgrade the API jars without hacking the server? (That is particularly true on WebLogic and WebSphere where you'll immediately lose support in that case.)
"Near complete" is seriously misleading there. Even if we pretend that Seam 3 was available in the first place, all you'd get is a bit of CDI (but not integrated with other parts of the EE server) and possibly a JAX-RS provider added, that's it - when talking about deploying the not-yet-existing Seam 3 onto a general Java EE 5 server. Tomcat of course is a different story since you may at least upgrade the JPA and JSF APIs freely there.

Let's be real though - if your IT organization is worth it's salt technically, you can't tell me that you wouldn't be upgrading WLS (or any other piece of major hardware/software in your IT organization) in a relatively short period of time after it is released - particularly if you have an extended maintenance contract like most people do. And if that's true of a very large company like yours, do you really think this is that big an issue for most organizations - come on man!

This *is* a very serious concern in many IT organizations that have to deploy applications to a data center - a common case in the banking and government sectors. A server upgrade is driven by production concerns there, not by application development concerns. Even upgrading to a new WLS service pack can be a big deal there. Major server upgrades will only ever be considered once *all* applications running on that server have been proven to keep working, and even then only if that new major server version has been out for a year at least.
Essentially, application servers are treated like databases and operating systems there: Just like an Oracle database won't be upgraded if its present incarnation is proven to work for the organization, a data center's shared WebLogic/WebSphere installation is often managed in a similarly conservative manner. Sometimes the primary driver for upgrades is the vendor's end-of-life announcement for that particular server version!
This is not a "red herring" by any means. I was working as a consultant in the banking and government sector for years, next to developing Spring as a framework, and experienced this all the time. Reza, you obviously never worked in that kind of environment; please accept that you are not in a position to make general judgments about it a la "let's be real" and "this is really a red herring" then. You are maybe living in a different world and having different clients; all the power to you for those - as long as you respect that there are other environments as well.
Juergen

You are maybe living in a different world and having different clients; all the power to you for those - as long as you respect that there are other environments as well.

Man, here you go again with the overkill character assassinations whenever something doesn't suit your purposes...FYI I just helped with the WebLogic 10 upgrade for one of the largest companies in the world not so long ago and I know of a WebSphere 7 upgrade going on right now at one of the largest insurance companies in the world! Didn't you note that most people find this silly and suspicious? Almost all of my JBoss, GlassFish and WLS customers are now at Java EE 5, only the WebSphere guys are lagging behind and they are gradually upgrading too, even local and state government organizations...!
As to Seam 3/Weld (or any other pluggable JSR 299 implementation for that matter), the point is that you can use them well-before some commercial guys come up with their Java EE 6 server implementations and upgrade *when* you can. Seam users on WebSphere are a great use-case for a API set and programing model such closer to Java EE than Spring is or likely will ever be.
Note the *when* part. It's what you Spring guys keep missing (perhaps deliberately). All application servers *sooner or later* need to be upgraded for the simple fact that vendors do not support any given version forever. And since any sane company that pays for a license also has a maintenance/support plan, upgrade cost is a non-issue. This means that when upgrades happen is really a function of whether the development teams see value in an upgrade. That's a *political* and not a *technical* concern. As I see it, Java EE 6 provides plenty of reasons to upgrade, certainly over J2EE. That's of course the political dysfunction you are trying to encourage. You are right I don't live in such a cynical world :-).
The the upgrade is so hard it should be avoided at all costs argument is silly. Most IT departments do major hardware and software upgrades on a routine basis. Thet's part of their day-to-day job and they don't suck at it. I've been through a few at this point and while it isn't trivial, it also is not that difficult either, even for a large company. Most IT organizations that care about developer productivity certainly see that as worth the effort (case in point the previous post by the JBoss user).
Hope it helps,
Reza

FYI I just helped with the WebLogic 10 upgrade for one of the largest companies in the world not so long ago and I know of a WebSphere 7 upgrade going on right now at one of the largest insurance companies in the world!

Can you please elaborate on the steps that you guys had to do before the upgrade? The reason I ask is because while reading your comment, I get a feeling that upgrading the app servers seems to be so simple. May be, I am missing something and could learn from your experience. I specifically want to know if:
a. App server was deployed in multiple data centers hosting multiple applications possibly developed by different teams?
b. Did you guys had to plan for new hardware/utilization before the upgrade? (right from dev, qa, uat to prod)
c. Upgraded from what version of Weblogic? Did you guys had to make any changes to existing artifact or code?
I understand relatively small organizations don't have to go through all these but since you mentioned that it was one of the world's largest Insurance provider, I am curious to know. Please note that there is no personal attack here and I just trying to understand so that my team could benefit from that.

Almost all of my JBoss, GlassFish and WLS customers are now at Java EE 5, only the WebSphere guys are lagging behind and they are gradually upgrading too, even local and state government organizations...!

As to Seam 3/Weld (or any other pluggable JSR 299 implementation for that matter), the point is that you can use them well-before some commercial guys come up with their Java EE 6 server implementations and upgrade *when* you can.

JSR 299 is just one part of the EE6. What about the others? Even otherwise, how much portable is J2EE app into a JEE6 container? There will be a considerable amount of change right from the deployment descriptors to the way application is packaged. Let's say I go through that exercise and port to JEE6. Come JEE7,I will have to go through that again (based on the history).

Seam users on WebSphere are a great use-case for a API set and programing model such closer to Java EE than Spring is or likely will ever be.

Not in my books. Again this is just individual opinion and no harm in disagreeing, I hope.

And since any sane company that pays for a license also has a maintenance/support plan, upgrade cost is a non-issue. This means that when upgrades happen is really a function of whether the development teams see value in an upgrade.

In large (sane!) organizations, it is far from reality. Consider an existing application that is running fine on WebLogic 7 and requires no functional changes. Just because the App server is at end of life and because contract cannot be renewed, we are forced to upgrade to WebLogic 10. What is the benefit here?

The the upgrade is so hard it should be avoided at all costs argument is silly.

Upgrades are not silly. I am painfully aware because it costs lot of money and time. Any argument to say that it is silly in my opinion is just a way to avoid technical reasoning behind that.

Can you please elaborate on the steps that you guys had to do before the upgrade?

Sure no problem, I'll be happy to share what I reasonably can (very minor point, the WLS upgrade is not with an insurance company, the WebSphere upgrade is). Please do respect my time and keep this reasonable for the scope of a forum post, though. If you want to learn about upgrade procedures, I would suggest the best resource is your own IT team which I am sure has gone through more than one of these or contact your WLS sales rep who can help you with it if you need help. One thing I do need to keep an eye out for is not to reveal so much detail that it becomes obvious who the client is. Then I'll be in trouble for potentially breaking confidentiality agreements...
We upgraded from WebLogic 9.2 to 10.3, and no real code changes were necessary (I seem to vaguely recall some minor JSP compilation issues, but that was about it). It was a relatively large cluster of machines with multiple applications developed by multiple teams. Because of 24*7 up-time guarantees like you have, the organization had a DR/back-up site, which was activated while the production site servers were being upgraded and all application re-deployed/tested. Once production was upgraded, the DR site was taken off-line and upgraded in turn. For QA and DEV, servers were upgraded on an ad-hoc basis, off-hours since up-time was not that big of a deal there. Yes, we did perform an associated hardware upgrade, capacity planning and stress testing, as is usually the case with most major upgrades.

JSR 299 is just one part of the EE6. What about the others? Even otherwise, how much portable is J2EE app into a JEE6 container?

As I mentioned, porting from WLS J2EE to Java EE 5 was not a big deal at all since Java EE takes great pains to maintain backwards compatibility and so do all major Java EE vendors. As to Seam 3, other than CDI I would be utterly shocked if they will not support all major pluggable Java EE APIs including JSF 2, JPA 2, JAX-RS and bean validation (just as Spring 3 does). If you really have a sincere interest, nothing is stopping you from getting on the Seam forums and asking questions yourself about their specific plans: http://seamframework.org/. We certainly plan to have similar support for our JSR 299 implementation, CanDI. I think the Apache guys are going so far as to support EJB 3.1 in a pluggable fashion via OpenEJB for their JSR 299 engine.

Just because the App server is at end of life and because contract cannot be renewed, we are forced to upgrade to WebLogic 10. What is the benefit here?

Frankly you are twisting what I am saying. I didn't say upgrades are silly, just that they are a *normal* and *essentially unavoidable* part of being a functional IT shop that would like to fully utilize their software licenses. The only question is the decision *when* to upgrade. Progressive shops upgrade proactively, especially when there is a good reason for it, like Java EE 6 from J2EE. Conversely, a shop whose upgrade schedule is mechanically dictated by product end-of-life is obviously pretty regressive/stodgy/short-sighted/pessimistic. That's most certainly not what I see in my clients.
What's silly is overemphasizing software upgrades to be some kind of herculean effort, which it is not. People do that successfully all the time, including your own organization judging by your WLS version in use. And the more frequently it is done, the easier it is, hence the importance of being on a regular upgrade cycle.
Now, all that being said, it could indeed be true that upgrades are hard in your particular environment for whatever combination of reasons. It's a leap to go from that to saying upgrades are hard in general so we should all use Spring for that reason. If that's the only reason to be stuck with Spring, I would say that's pretty unfortunate...
Hope it helps,
Reza

Reza
moving from J2EE 1.4 (EJB2 etc) to Spring 1.2, then Spring 2 and now Spring 2.5 was a real breath of fresh air and a major development productivity boost (testing is so much easier). Now I have read your "EJB 3 in action" book and I can see that the programming model is much simpler (especially entity beans which is very similar to Hibernate which we are now using).
However we have just upgraded to WebLogic 10.3 (from WebLogic 8.1) which is great because that allows us to use Java 5. However it was not cheap and I do not expect we will get another upgrade (we have a large site with over 50 test and live WebLogic domains) for two years. I know you do not like this but for larger installations this is a fact that I think you need to acknowledge. I do note that some of the API are pluggable and that is a good move.
In general I do think that Java developers need to understand both Spring and JEE and work out what is best for their current project. For my current project it is Spring but I am certainly not afraid to compare both when I get to start on something new

Steve,
Again, I am not saying it is a cakewalk in every case - just that it is a pretty normal part of doing business and not something to especially dread.
After all, you guys did accomplish it and benefit from it, right? If you can do it, imagine how much simpler it is for a vast majority of companies that really don't need to achieve very large scale or 100% up-time and typically have a maintenance plan that includes a right to upgrade. For one, they could do the upgrade gradually on a per cluster/server basis as need arises/the IT guys can budget man-power.
BTW the two-year cycle you mentioned is pretty typical and not that bad (in fact, I doubt WLS is going to be released before next year), especially given that you are now at Java EE 5 and could essentially use all the pluggable APIs. Indeed, one of the goals of the CDI spec was to be able to support Java EE 5 environments for this exact reason (Gavin could clarify what his exact plans are in this regard for Weld/Seam 3). As I said this is certainly something we are keeping an eye on for our pluggable JSR 299 implementation.
Finally thanks for the kind words on the book as well as the balanced stance on technology adoption. Do let me know what else we can do for Resin/CanDI/Java EE 7 (short of attempting to make EJB 3.1 and Servlet 3.0 pluggable:-)).
Cheers,
Reza

Reza,
I can tell that you are very passionate and convinced about JEE6 but from reading the your entries in this thread I'm not convinced you are doing a good job selling JEE6. Most of your statements are contradictory and when people point them out you say they are making personal attacks against you.
From the look of things,Spring is working well for a lot of people and solving their problems. If you want them to use a 'better' alternative you can't simply dismiss the challenges that they have/had as non-issues.
You have to provide them with a compelling alternative that really address their current challenges. At the end of the day if JEE6 make sense to you use it and likewise for Spring.
This is my mere honest contribution and is not in anyway meant to be a personal attack.
Thanks.

Gofhaone,
You are of course entitled to your own opinions. I am just trying to honestly state things the way I see them, nothing more and treat everyone's comments with due weight the best humanly I can. And I would certainly appreciate your pointing out exactly what you find contradictory...Indeed, consistency is something I value as a fan of formal logic so it would be good to know. If anything needs clarification, I am happy to do it.
As to what Java EE 6 offers over Spring, I feel I've sufficiently answered that numerous times despite it not really being my job (just look around on my website a little not to mention the recent heated discussion on the GlassFish/Java EE 6 thread). I'd rather not open that can of worms again if you don't mind too much.
As far as "selling" Java EE, frankly I don't try to "sell" anything, especially because Resin/Java EE has enough traction on its own and despite all the typical nay-saying. In fact, I'm not particularly thrilled to even carry on this thread any farther than is absolutely necessary...I'm just responding as I see needed (the same as Gavin and the others I am sure).
Cheers,
Reza

So is it really the case that the best arguments for the use of Spring instead of Java EE 6 are that:
1. upgrading a WebSphere or WebLogic deployment is hard, and
2. a full Java EE server occupies more disk space than the Spring jars?
Then I suppose Java EE has already won the debate. Surely you guys can come up with something better than these totally lame reasons to use Spring instead of EE6??
Oh, and if you want my take on (non-)problems 1. and 2., here you go:
1. Use JBoss, GlassFish or Resin. They're not hard to upgrade. That's the great thing about the EE ecosystem: choice. BTW, if you want to make use of Servlet3 - and you probably do - then you're going to have to upgrade your appserver *anyway*, whether you're using Tomcat, Jetty, WebSphere, WebLogic, JBoss, GlassFish, Resin or something else.
2. In a very short time, Caucho, JBoss, and other vendors, will release small, non-"bloated" EE 6 web profile implementations.

This *is* a very serious concern in many IT organizations that have to deploy applications to a data center - a common case in the banking and government sectors. A server upgrade is driven by production concerns there, not by application development concerns. Even upgrading to a new WLS service pack can be a big deal there. Major server upgrades will only ever be considered once *all* applications running on that server have been proven to keep working, and even then only if that new major server version has been out for a year at least.
Essentially, application servers are treated like databases and operating systems there: Just like an Oracle database won't be upgraded if its present incarnation is proven to work for the organization, a data center's shared WebLogic/WebSphere installation is often managed in a similarly conservative manner. Sometimes the primary driver for upgrades is the vendor's end-of-life announcement for that particular server version!
This is not a "red herring" by any means. I was working as a consultant in the banking and government sector for years, next to developing Spring as a framework, and experienced this all the time. Reza, you obviously never worked in that kind of environment; please accept that you are not in a position to make general judgments about it a la "let's be real" and "this is really a red herring" then. You are maybe living in a different world and having different clients; all the power to you for those - as long as you respect that there are other environments as well.
Juergen

+1. Agree with everything here. My experience has been similar with banks. They are very conservative.
I remember a conversation with an admin. The first thing he told us was: "Stability is more expensive than cost of the software, hardware or application costs"
Every point upgrades of a database/server is taken as a project and huge time and costs go for it as budget.
Reza, most application developers aren't as luck as you are!
Often open source projects go through through review (for licensing implications and many others I'm not aware of) for a period of several months, before they are approved for production use. So, even with a Spring upgrade it's not so easy, but much less painful.

Please don't get me wrong on this, I do indeed sympathize and have seen this kind of mindset in action (sadly). All I'm saying is that it isn't necessary to passively accept this as convention, especially without even making an effort. I've personally often found that taking initiative does pay off, perhaps to your own surprise (especially if you have the power to make positive change). At the end of the day, I think a lot of people do listen to good reason and try to do the best job that they can if possible. Folks in corporate IT are no exception...
All that being said, I do understand that there are stodgy companies out there (especially in this economic environment). Let's just hope that's not what everyone's situation is. And if you want, solutions like Seam are there for you as is Spring (clearly)...
Cheers and talk to you guys again soon (got a few meetings to take care of until late afternoon).
Reza

Senthil,
No one is saying that upgrading app servers is trivial.
Let's be real though - if your IT organization is worth it's salt technically, you can't tell me that you wouldn't be upgrading WLS (or any other piece of major hardware/software in your IT organization) in a relatively short period of time after it is released - particularly if you have an extended maintenance contract like most people do. And if that's true of a very large company like yours, do you really think this is that big an issue for most organizations - come on man!
This is really a red herring more than anything else and way too much of an overemphasized concern IMO, especially considering most application development cycles...
Cheers,
Reza

But you did. You said it is harder upgrading an included jar than it is to upgrade a bloated jee server. The reality is, most organizations, who value their shareholders, do not upgrade server software just because some vendor driven committee pushed out a new spec version which forces organizations to buy new super expensive application servers.
Smart IT organizations look to leverage their investments as long as possible and one way to do that is to leverage frameworks which live outside a vendor driven spec treadmill. Spring allows for this and best of all, it costs zero dollars.
If my company is using Weblogic Server, Websphere, etc..., i can freely use Spring on it without issue. But when useing J2EE, JEE, or whatever it is called this year, you have to upgrade an entire server just to take advantage of something which a simple spring jar can include on top of a server.
Maven + Spring = simple development which deploys on _any_ java server. JEE = specific version of a server and it is not portable to non-jee specific version compatible versions.
enough on this topic. if you want to use jee, go ahead, i make lots of money ripping out bloated, slow j2ee\jee apps and replacing them with light weight, fast, spring apps.

I'm not sure where the 0% comes from? Are you ref. to non-Java solutions?

No, he is referring to JEE versions. Like, you can not run a JEE6 app on Weblogic 10.3 for example. With Spring, i can run Spring 3.0 on Weblogic 10.3 with no changes other than the container specific files if you are using things like Weblogic JDBC connection pools.

"proprietary" - I don't think this word means what you think it means. In fact, Spring is obviously the proprietary technology while Java EE is an open, standard specification. If you pick Spring, you get Spring. If you pick Java EE, you're free to choose an implementation/vendor that you like.

No. The difference between proprietary and not proprietary is the license under which the code is released. It has nothing to do with who the commiters work for.

"proprietary" - I don't think this word means what you think it means. In fact, Spring is obviously the proprietary technology while Java EE is an open, standard specification. If you pick Spring, you get Spring. If you pick Java EE, you're free to choose an implementation/vendor that you like.

No. The difference between proprietary and not proprietary is the license under which the code is released. It has nothing to do with who the commiters work for.

No. An API based on an open specification for a platform that anyone can implement is NOT proprietary. An API based on a platform from a single vendor, regardless of license, is proprietary.
Proprietary has little to do with license. You can make a weak argument that because something is open source, it isn't proprietary, but that only holds water if you or the community are willing to maintain the thing if it's ever abandoned. So, you can claim that the Spring framework isn't proprietary, but what are you going to do if SpringSource (VMWare) goes out of business? Are you prepared to support the entire Spring framework, or rely on the open source community to do it for you? If so, that's fine. It's probably very low risk since VMWare isn't likely to go out of business (I assume), and the community would probably pick up the Spring framework and keep it going just fine. That doesn't change the fact that it's the only implementation, it's controlled by a single entity, and therefore proprietary.
On the other hand, Java EE is not proprietary at all. The spec is open, the APIs are open, and there are multiple competing implementations that will all run a Java EE application. I'm not going to bicker about the politics of the JCP because that's just hair splitting. The platform is obviously not controlled by a single entity, regardless of your feelings about the JCP. If we were having this discussion in the year 2002, you'd be a lot closer to right. However, time marches on.
And finally, I am NOT bashing the Spring framework. I'm responding to the Spring zealots who continue to claim that Java EE is expensive, proprietary, and bloated when it is demonstrably free, open, and increasingly light weight. Use whatever technology you want, but I wish people would quit making ridiculous claims like this.

I am working in one of the world's largest financial firms and have no affiliation with Spring Source. I am a very happy Spring user and not anti-JEE. Not just I, the entire team is happy with Spring and I would even go as far as to say that no new projects are started without considering Spring and in most of the cases adopting Spring. The reason Spring is so obvious choice, is because:1. Adopting earlier version of J2EE made not just the development miserable but a maintenance nightmare.2. I personally worked on projects that were re-architected from an EJB based to a Spring based solution and running fine in Production for more than 4 years without any issues that were caused by earlier JEE compatible implementations.

Now, I understand that I am basing my arguments on an earlier version of JEE and not based on the merits of JEE6.My point is, just as Spring has to prove its worth and return on investment before its wide spread adoption, JEE6 has to prove its merit. You and Gavin bring up the same questions on 5 different forums and saying Spring is not implementing CDI and so you have to use JEE is not helping either. Also lot of Organizations have invested heavily on Spring and to move away from that you really need to give a better technical reasoning than saying Spring is NOT JEE compatible. As of yet, we do not have any technical reason to move away from Spring. And, we don't really care that our application is JEE compatible as much we care about simplicity and maintenance (we are like that past 5 years or so and our applications are doing just fine). Again, this is just my experience over a decade long career implementing critical enterprise applications in Java (a lot of my friends working in even smaller Organizations have the same opinion) but yours could be different.

Now, help me understand this:1. Why would I move away from a Spring based solution which I can run on any server to a new spec that has no single production application implemented yet? (Lot of our applications run on WebLogic and recently we are moving towards tomcat based solution) 2. What is that I cannot do with Spring that I will be able to do with JEE 6? I don't buy the argument of portability because my Spring application is really portable to any app server.3. The most important of all: Other than saying, we are not JEE compatible, which my business users don't care, what is the argument for me to go to my business and ask for money so that we can start the new projects ground up using JEE6 and forfeit the investments made so far in Spring?

I hope you can help me answer this questions so that I get a better understanding. Thanks.

+1 - All very valid questions. I would like to hear what Reza and Gavin have to say about this. I am tired of seeing Reza, Gavin, Jeurgen et all arguing/counter arguing the same points in different threads/forums. As Senthil mentioned, everyone needs to understand that Spring grew in popularity because of its timing and simplicity (best alternative in older JEE days). No argument that JEE 6 is orders of magnitude better than Older JEE. Whether its better than current Spring or not is only an academic argument. Spring has the inertia and momemntum of the past few successful years where it penetrated into developer and enterprise hearts which were dejected with older JEE.
Newer projects with little or no vested investments in Spring, I am sure, will definitely look at JEE 6 due to its merits alone and not just because it is the latest standard (people burnt their hands earlier with older EJB 'standard's! ) and that Gavin/Reza have successfully beaten down Jeurgen with their arguments in blog posts.
Projects heavily invested in Spring will continue to do so, until they find JEE6 a more attractive and worthy (and easier to transform to) alternative in terms of ROI.
Spring will continue to bridge any gap to JEE 6, at its own pace and as per demands of its users (or if and when they see people jump ship to JEE 6 gradually).
The bottom line is that, people won't use JEE6 just because its a standard. And frameworks/products like Spring won't just suddenly overhaul and become compliant to a standard just because it is a standard. Have'nt such prodcuts in fact proven that they can be succesful by going against a standard and listening to the pains of developers and solving them in simple, staright forward manner !!
Nothing against JEE 6. But it has yet to win the hearts of developers (and enterprises) based on its merits and ease of use. And no amount of arguments that it is to be the 'chosen technology because its a standard' are likely to win any adopters sooner than due course of time.
I personally, like the bunch of improvements that JEE 6 has to offer, and very much looking into it despite/inspite of arguments in all these threads/blogs. May be, at least one good side-effect of such arguments is that people at least become aware of what each tech has to offer :)
(Captcha: "Looneys In" !)

I am using Spring since 1.2, so i have seen some releases since then. To me, for a major release, this is not a big shot. I admit that something like @Async is nice but i am missing some fundamental inovations. To me it appears like a "we are now Java5 compliant and we use generics now".
We have another way of defining Beans (JavaConfig) now inside the framework. Hmmm ok, nothing i would die for. We have a Spring EL feature. Hmmm. Ok. Never missed something like that. Somthing like @Scheduled can be useful here and there but it will never replace a sheduling system you might want to use anyway.
Of course there are important enhancements in terms of new API versions support like JPA2. Features like REST support...boy. People using Spring for some time do use projects like CXF anyway and people like that dont need any REST implementation inside the framework. If you want to change sides and replace specialised frameworks then supply JAX-* compliant APIs. But i dont think you can compete with something like CXF.
IMO this is a perfect 2.8 or whatever release but for a 3.0 release, one simply expects something REALY inovative.
Marc Logemann
http://logemannreloaded.blogspot.com

Hi Mark,
Ryan Slobajan summed up his perspective, with matches ours, for the primary reason this version was tagged 3.0:

I think that the major revision number is most definitely applicable to this release, and it's due to the very first feature listed - Spring 3.0 now requires Java 5. That means that all of the J2SE 1.4 support has been removed, and things like generics and annotations are now used throughout the codebase. That is a major, breaking change and for that reason it should have a major version increment. If I was to guess, I'd also say it was a lot of work - moving all of those application servers over to Java EE 5 was a major undertaking that took a long time, and it was definitely worthy of a major version increment.

With that said, there are many useful new features in this release as well, many of which we are covering now for users in a series of blogs starting with http://bit.ly/6sj3Dk. But I, Juergen, and the rest of the team will be the first to tell you 3.0 overall is an evolutionary release that rounds off the key programming model advancements introduced in Spring 2.5.
One point regarding REST--I think you may be getting hung up on the "REST" acronym there. In my experience, I've found REST means different things to different people. For our purposes, we had concrete user demand for better support in Spring MVC for development web applications that can support a variety of client types, including JavaScript/Ajax, Flex, and GWT clients. Spring 3.0 sets a foundation for this that builds on the popular MVC @Controller programming model introduced in Spring 2.5.
Best regards,
Keith

Marc,
In addition to what Keith (and Ryan) said already, I'd like to give a bit of insight into the version naming story here.
As you'll remember, we went from Spring 2.0 to 2.5 two years ago: quite a significant leap in the version number but an even more significant leap in the programming model when running on Java 5. There were serious debates about calling that release "Spring 3.0" back then already, but simply speaking, two things were holding us back: The release was still compatible with Java 1.4 as well (albeit with limited functionality), and there were hardly any changes to the core since 2.0. So we chose the "2.5" option, basically saying that this is "half way to 3.0" in that it provides as much functionality as possible on the basis of the 2.0 core - leaving a comprehensive completion step for 3.0 when we go fully Java 5+.
Now, with the present-day Spring 3.0 release, we are completing this picture. There are significant new features in the core programming model, of course, from @Configuration classes to JSR-330 and also @Value with its expression language support. But even more significantly, the entire Spring core codebase with its APIs and SPIs has been revisited for a thorough Java 5+ upgrade. This may not in itself be a big-bang feature but when working with it, I'm sure you'll appreciate many of the refinements there. For two examples, take generified ApplicationListeners with their event type narrowing, and the new ConversionService facility which is basically a modern-day alternative to PropertyEditors.
Another way to see it: Spring 2.5 was Spring 2.0 + 0.5... Now, Spring 3.0 is Spring 2.5 + 0.5. That 0.5 delta is pretty much an accurate reflection in both cases, and was a reason for choosing the 3.0 label as well.
As a further note, the revised Spring 3.0 core is also the basis for higher-lever features in related projects such as Spring Integration 2.0 and Spring Web Flow 3. This is all going to reveal in 2010, next to the Spring Framework 3.1 release, so I hope you'll find a more obvious 3.x picture then.
Hope that helps,
Juergen

1. Why would I move away from a Spring based solution which I can run on any server to a new spec that has no single production application implemented yet? (Lot of our applications run on WebLogic and recently we are moving towards tomcat based solution) 2. What is that I cannot do with Spring that I will be able to do with JEE 6? I don't buy the argument of portability because my Spring application is really portable to any app server.3. The most important of all: Other than saying, we are not JEE compatible, which my business users don't care, what is the argument for me to go to my business and ask for money so that we can start the new projects ground up using JEE6 and forfeit the investments made so far in Spring?

I hope you can help me answer this questions so that I get a better understanding. Thanks.

If you're happy with Spring, by all means keep using it. Spring is 'just' a competing technology. You could just as well ask why an existing .NET user should switch to Spring. Oftentimes, there isn't a truly compelling reason. They are all fairly mature and capable technologies.
The main problem is that you are always trying to persuade Java EE users to adopt Spring. Java EE news and releases are bad mouthed with replies like: "Is this still relevant? Use the original! Use Spring! EJBs are old and 2002!".
For me it's completely the other way around. We have a large investment in Java EE, both in terms of code as well as in terms of knowledge. There is basically no reason at all for us to forfeit those investments and switch to Spring. We're very productive in Java EE and everyone likes the programming model. The overwhelming majority of the problems we have seen with Java EE during the last few years have been addressed by Java EE 6, so for us this is a completely logical path to follow.
If you're a new user, without any investments in either Spring or Java EE, I would personally advice to start with Java EE. It's easier, simpler, more type safe and the web front end is component based instead of Spring's action based approach. In the end it's a matter of choice perhaps, but I think component based frameworks are just nicer to work with. I also really like EJBs stateless session beans. A simple annotation and I have a bean with really smart transactional behavior. A simple other annotation and I have an entitymanager, which gives me access to a very powerful ORM solution. It's also trivial in EJB to make a method asynchronous, with smart defaults for locking and optionally a very simple way of tuning the locking behavior.
So basically, EJB lets me write a POJO, and with just a few very simple annotations which have an extremely low mental overhead, complex stuff like transactions, concurrency, handling an ORM manager (closing connections, lifecyle) and parallel/asynchronous execution is all taken care of for me. For us these are very important functions and the fact that even interns and junior programmers are able to use those within minutes means a high productivity gain for us.
Captch: large trues ;)

is there really this much of a reactionary movement to spring or is this board flooded with oracle employees?
dunno. my stand is that until the application server market is commoditized in the same way that tomcat has commoditized the servlet container market, i have no interest in looking at EE technologies. I just don't believe that the productivity gains are worth the costs.

1. Why would I move away from a Spring based solution which I can run on any server to a new spec that has no single production application implemented yet? (Lot of our applications run on WebLogic and recently we are moving towards tomcat based solution) 2. What is that I cannot do with Spring that I will be able to do with JEE 6? I don't buy the argument of portability because my Spring application is really portable to any app server.3. The most important of all: Other than saying, we are not JEE compatible, which my business users don't care, what is the argument for me to go to my business and ask for money so that we can start the new projects ground up using JEE6 and forfeit the investments made so far in Spring?

I hope you can help me answer this questions so that I get a better understanding. Thanks.

If you're happy with Spring, by all means keep using it. Spring is 'just' a competing technology. You could just as well ask why an existing .NET user should switch to Spring. Oftentimes, there isn't a truly compelling reason. They are all fairly mature and capable technologies.

The main problem is that you are always trying to persuade Java EE users to adopt Spring. Java EE news and releases are bad mouthed with replies like: "Is this still relevant? Use the original! Use Spring! EJBs are old and 2002!".

For me it's completely the other way around. We have a large investment in Java EE, both in terms of code as well as in terms of knowledge. There is basically no reason at all for us to forfeit those investments and switch to Spring. We're very productive in Java EE and everyone likes the programming model. The overwhelming majority of the problems we have seen with Java EE during the last few years have been addressed by Java EE 6, so for us this is a completely logical path to follow.

If you're a new user, without any investments in either Spring or Java EE, I would personally advice to start with Java EE. It's easier, simpler, more type safe and the web front end is component based instead of Spring's action based approach. In the end it's a matter of choice perhaps, but I think component based frameworks are just nicer to work with. I also really like EJBs stateless session beans. A simple annotation and I have a bean with really smart transactional behavior. A simple other annotation and I have an entitymanager, which gives me access to a very powerful ORM solution. It's also trivial in EJB to make a method asynchronous, with smart defaults for locking and optionally a very simple way of tuning the locking behavior.

So basically, EJB lets me write a POJO, and with just a few very simple annotations which have an extremely low mental overhead, complex stuff like transactions, concurrency, handling an ORM manager (closing connections, lifecyle) and parallel/asynchronous execution is all taken care of for me. For us these are very important functions and the fact that even interns and junior programmers are able to use those within minutes means a high productivity gain for us.

The main problem is that you are always trying to persuade Java EE users to adopt Spring. Java EE news and releases are bad mouthed with replies like: "Is this still relevant? Use the original! Use Spring! EJBs are old and 2002!".

I'm not sure if this has any relevance to question asked. Eve if it did, it's probably the most amateurish.

and the web front end is component based instead of Spring's action based approach

Bad answer. Spring doesn't force MVC on you. It's a choice. In fact, you are under no pressure to choose Spring MVC, even if you wanted to use an action framework.

I also really like EJBs stateless session beans. A simple annotation and I have a bean with really smart transactional behavior. A simple other annotation and I have an entitymanager, which gives me access to a very powerful ORM solution.

Congratulations! This is the first answer closer to what was being asked. I know this was really simple with EJB. However, is this a drastic simplification? I'm not so sure.

So basically, EJB lets me write a POJO, and with just a few very simple annotations which have an extremely low mental overhead, complex stuff like transactions, concurrency, handling an ORM manager (closing connections, lifecyle)

Spring lets you do POJO, and makes it easy to implement whatever you mention above. In fact, it goes a step further and makes it easy to manage with out use of an ORM. I can add Spring to an application that is currently not using EJB at all, and is running on a J2EE server. It makes these happen even with applications that are not run in an application server.

For us these are very important functions and the fact that even interns and junior programmers are able to use those within minutes means a high productivity gain for us.

Simplicity is good for everyone. However, it's important that people learn about choices.
It's easy for the Spring crowd to learn about EJB 3, as they are working with the source of EJB 3 inspiration. This is not arrogance, it's only a way of looking at things.
It's wrong to assume that in Java career, people need to choose between Spring or EJB 3. They need to know both to make an informed judgement about either, and when to use what etc.

I am working in one of the world's largest financial firms and have no affiliation with Spring Source. I am a very happy Spring user and not anti-JEE. Not just I, the entire team is happy with Spring and I would even go as far as to say that no new projects are started without considering Spring and in most of the cases adopting Spring. The reason Spring is so obvious choice, is because:1. Adopting earlier version of J2EE made not just the development miserable but a maintenance nightmare.2. I personally worked on projects that were re-architected from an EJB based to a Spring based solution and running fine in Production for more than 4 years without any issues that were caused by earlier JEE compatible implementations.

Now, I understand that I am basing my arguments on an earlier version of JEE and not based on the merits of JEE6.My point is, just as Spring has to prove its worth and return on investment before its wide spread adoption, JEE6 has to prove its merit. You and Gavin bring up the same questions on 5 different forums and saying Spring is not implementing CDI and so you have to use JEE is not helping either. Also lot of Organizations have invested heavily on Spring and to move away from that you really need to give a better technical reasoning than saying Spring is NOT JEE compatible. As of yet, we do not have any technical reason to move away from Spring. And, we don't really care that our application is JEE compatible as much we care about simplicity and maintenance (we are like that past 5 years or so and our applications are doing just fine). Again, this is just my experience over a decade long career implementing critical enterprise applications in Java (a lot of my friends working in even smaller Organizations have the same opinion) but yours could be different.

Now, help me understand this:1. Why would I move away from a Spring based solution which I can run on any server to a new spec that has no single production application implemented yet? (Lot of our applications run on WebLogic and recently we are moving towards tomcat based solution) 2. What is that I cannot do with Spring that I will be able to do with JEE 6? I don't buy the argument of portability because my Spring application is really portable to any app server.3. The most important of all: Other than saying, we are not JEE compatible, which my business users don't care, what is the argument for me to go to my business and ask for money so that we can start the new projects ground up using JEE6 and forfeit the investments made so far in Spring?

I hope you can help me answer this questions so that I get a better understanding. Thanks.

This is an excellent post. Spring was the first big winner in the enterprise Java space, that beat EJB 2 hands down.
Now, if JEE 6 must win, they must demonstrate value over Spring. Does it dramatically simplify development when compared to Spring? Does it bring in obvious cost savings or productivity benefits that can be quantified, measured?
We hear a lot of arguments, and counter arguments but there is no quantification happening.
I agree that Spring had it easy competing with EJB 2. They were competing with a complete loser then. Folks supporting JEE should stop talking about MB's of saving, not having to copy required jar's or about eliminating XML etc.
Folks on the Spring side should also not get very emotional the moment they hear EJB. Unfortunately, they all think EJB 2.
I hope this discussion starts moving in a more positive direction, for the Java community to benefit. I usually see Reza, Gavin & Spring folks attack each other, name calling etc. This does not help the community, except to increase fragmentation, and making people more suspicious about either of JEE/Spring.
You are matured folks, and have high respect in Java ecosystem. So, get over this silly business of attacking each other, and help everyone to move forward. Otherwise, people will begin to ignore, even if what you wanted to say was really important.

Now, if JEE 6 must win, they must demonstrate value over Spring. Does it dramatically simplify development when compared to Spring? Does it bring in obvious cost savings or productivity benefits that can be quantified, measured?

Actually, this is kinda *your* responsibility. We can deliver great specifications, and solid implementations of those specifications to the community. It's part of your responsibility to your employer to properly investigate all options (in the Java space and beyond), actually try them out, and make an informed decision as to what middleware provides the most benefit to your business. There's nothing I can say to you that can prove to you that EE 6 is great. You have to try it out for yourself.

Now, if JEE 6 must win, they must demonstrate value over Spring. Does it dramatically simplify development when compared to Spring? Does it bring in obvious cost savings or productivity benefits that can be quantified, measured?

Actually, this is kinda *your* responsibility. We can deliver great specifications, and solid implementations of those specifications to the community. It's part of your responsibility to your employer to properly investigate all options (in the Java space and beyond), actually try them out, and make an informed decision as to what middleware provides the most benefit to your business. There's nothing I can say to you that can prove to you that EE 6 is great. You have to try it out for yourself.

I failed to convey what I meant to say. By *they* I meant the set of technologies, not it's proponents. JEE is a standard, so everyone in Java space sort of have a responsibility to check it out -- I know many Spring fans will disagree with me on this.
However, I disagree with some folks in JEE camp who hold the view that Spring is creating an unnecessary fragmentation, and that we should all work towards adopting JEE, as it's a standard. Such calls for charity rarely gets acceptance.

I failed to convey what I meant to say. By *they* I meant the set of technologies, not it's proponents. JEE is a standard, so everyone in Java space sort of have a responsibility to check it out

I think that's right. And I'm very confident that a very large percentage of those who do actually try out EE 6 will end up deciding that it's the right platform for them. Of course, some people won't like it, and will decide to go somewhere else, and that's fine.

I know many Spring fans will disagree with me on this.

Exactly. And that's why a lot of us Java EE fans have a kindof disrespectful view the Spring fanboy set: many (not all) of them never actually get outside their little world to see what is available on the other side of the "fence". It's why you see Spring folks dissing Java EE on the basis of totally out-of-date arguments like "EJB (2) sucks" (have you looked at EJB 3.1?) or "Java EE containers are bloated" (have you noticed that EE 6 introduced a pruned-down web profile?).
The entire above discussion about jar sizes is completely out-of-date when you consider that the Java EE web profile implementations will be *much* smaller. (Of course, the jar size discussion is pretty much irrelevant anyway.)

However, I disagree with some folks in JEE camp who hold the view that Spring is creating an unnecessary fragmentation, and that we should all work towards adopting JEE, as it's a standard.

Unfortunately, this is a real problem. If framework (and application) developers could rely upon certain APIs (like JTA, or the CDI portable extension SPI) being available *everywhere*, then life would be just soooooo much simpler for everyone.
The mess that we've made of transaction management in enterprise Java is a disgrace. We've got abstractions of abstractions of abstractions .... all with the same three methods: begin(), commit(), rollback(). It's a total disaster. (I'm ashamed of my part in it - I should never ever have let Hibernate or JPA grow their own transaction management abstractions.)

I should never ever have let Hibernate or JPA grow their own transaction management abstractions.

Not sure if I understand this correctly. If that happened, would that mean if I want to use JPA for my school projects, I have to learn CDI as well?

Huh? What does CDI have to do with tx management?
You would use JTA, which has a user-visible API which is virtually identical to EntityTransaction, but is otherwise better in every way.
I've never understood why JTA is not part of Java SE. Considering all the incredibly crap and useless things that have been thrown into the Java SE SDK, the absence of a decent API for something as basic as transaction management is pretty embarrassing.

I've never understood why JTA is not part of Java SE. Considering all the incredibly crap and useless things that have been thrown into the Java SE SDK, the absence of a decent API for something as basic as transaction management is pretty embarrassing.

+1
Definitely agree with that. Maybe they felt transactions are too 'enterprisy' and aren't needed for Applets and Desktop applications? Stupid reason of course, but who knows...

I usually see Reza, Gavin & Spring folks attack each other, name calling etc. This does not help the community, except to increase fragmentation, and making people more suspicious about either of JEE/Spring.

Amen to this, it is something that I firmly believe and try to maintain the best I humanly can. In a way, responsible folks like yourself can help avoid this by calling a spade a spade when you see an individual/group of people (whomever they might be) moving things from a technical discussion into something far into the realm of character assassinations or making unsubstantiated statements. As in formal debate, this is almost always geared towards distracting from real issues.
Cheers,
Reza
P.S.: I'll have to admit I grew a little disgusted with this thread and abandoned it for a while. In case there are still unanswered questions that other folks did not already address, I am here to listen carefully and address them (hopefully as always)...

1. Nothing against Spring, but seems to me like they are trying to grow out of their purpose.
2. I wonder who would still be interested in EJB after having their fingers burnt already with all that bloatedness and politics! Not my technology of choice.
3. Look and learn from PHP. The value in quick development and deployment is priceless!
Albert.

Albert,
Have you taken a look at Java EE 6/CDI/EJB 3.1 lately (even SpringSource supports a majority of EJB meta-data, now including EJB 3.1 @Schedule and @Async)? What you are saying about Java EE simply has not been true for quite a few years and frankly is quite unfair. And I think Java EE 5/6 is quite easy to develop/deploy with (and so is Spring to a slightly lesser degree). Now, I am not saying PHP does not have merits, clearly it does have a very important role. In fact, Resin provides a Java-based PHP implementation that runs on top of Java EE.
Cheers,
Reza

Have you taken a look at Java EE 6/CDI/EJB 3.1 lately (even SpringSource supports a majority of EJB meta-data, now including EJB 3.1 @Schedule and @Async)? What you are saying about Java EE simply has not been true for quite a few years and frankly is quite unfair. And I think Java EE 5/6 is quite easy to develop/deploy with (and so is Spring to a slightly lesser degree). Now, I am not saying PHP does not have merits, clearly it does have a very important role. In fact, Resin provides a Java-based PHP implementation that runs on top of Java EE.

Cheers,Reza

Reza,
Springsource supporting JEE is not a function of just merit, we all know that.
Yes i have seen the changes u mentioned, though not as comprehensively. We can all quote these specifics for the sake of arguments, but the bigger picture doesn't prove it. Its much easier and sensible to plug in with just what you need rather than taking the whole big fat JEE.
Albert.

Yes i have seen the changes u mentioned, though not as comprehensively.

Since you are saying you haven't looked at things in detail, I am thinking there's no point in further discussion until you can talk about specifics. In my view the Java EE 6 Web Profile is exactly what is right for a majority of applications and goes to address your concerns over "big fat Java EE"...
Cheers,
Reza

I'm going to give you the benefit of the doubt here and not assume you are a "Spring zombie" despite the needlessly inflammatory post skimpy on details (perhaps deliberately)...
If you are talking about the "compatibility" concern, that is a *very* big deal that maybe you don't get since you don't actually work on a Java EE compatible product that has to pass the Sun compatibility test kit, which is no cakewalk by the way.
If it's *OK* if a company makes an honest slip in a blog post or a Tweet, but it is a very big deal if they are suddenly start *systemically marketing* their products as "Java EE compatible" when that is obviously not the case. The Spring framework and the SpringSource server offerings are especially troubling since both actively promote non-standard alternatives to Java EE APIs. More than what developers think, what sales people are pitching to non-technical IT staff like managers is the real concern here for folks like us (Resin) that bust our butts to earn the actual compatibility moniker...
If you are talking about the SpringSource *flap* about how Spring IoC supports everything that CDI does, that's rubbish pure and simple. Whatever name they wish to call me, they haven't managed to disprove a single thing I said:
* Sprig IoC is not type safe as compared to CDI (even with @Autowired).
* CDI Interceptors and Decorators are a lot more intuitive, easy to use and functional than Spring AOP.
* Stereotypes are far more powerful in CDI (now I understand they've made some changes in the very latest version to their idea of stereotypes to make it look more like CDI, but I still can't find any detailed documentation on it for the life of me).
* Spring scopes are just not an robust as CDI.
* The Spring SPI is a joke compared to the detailed and well-documented CDI SPI (Spring "SPI" basically means go dig around through tons of undocumented code scattered all over the place).
* CDI is much better integrated throughout the Java EE API stack.
* It's a patently ridiculous claim that Spring requires just as much configuration as Java EE does. Now, they've certainly made some improvements like the Java Config functionality that looks like a weaker counter-part to CDI producers/disposers but that doesn't solve the fundamental problem of Spring not being a platform...
So please, other than trying to slander me (BTW, it's interesting how I'm getting singled out for it despite other folks saying basically the same things - so be it, I guess I'm better equipped to deal with it), please, enlighten me on what details I missed out on...
Peace,
Reza

Yes i have seen the changes u mentioned, though not as comprehensively.

Since you are saying you haven't looked at things in detail, I am thinking there's no point in further discussion until you can talk about specifics. In my view the Java EE 6 Web Profile is exactly what is right for a majority of applications and goes to address your concerns over "big fat Java EE"...

Cheers,Reza

Reza,
Your passion for JEE is straightaway out of your commitment for it, so understandably you don't seem to get my point.
On another note, this venting out on the spring guys in the public forums is really childish, especially gavin's point by point criticism of spring, wonder whats the real motive here. Let the developer judge for themselves on what works for them.
Merry christmas,
Albert.

This venting out on the spring guys in the public forums is really childish.

Ummm...condescending much, especially given your obviously flame-bait, pointless post that folks other than myself have already responded to? Yet you seem to have picked me as a specific target to attack - wonder what your motives are? Why do you care about SpringSource so much?
I've always gone out of my way to make sure I am fair to anything Spring (and that's what's really irritating about the SpringSource personal attacks on me). Take a look here at my JBossWorld presentation: http://www.redhat.com/f/pdf/jbw/rrahman_320_spring_framework.pdf and my series of talks on integrating EJB 3 and Spring: http://www.shaunabram.com/spring_ejb3/. I won't even mention my first response to your post where I clearly indicated Spring is a good solution, just not as good as Java EE as I see it.

Especially gavin's point by point criticism of spring

Take a look at the last Java EE 6/GlassFish thread, that's where this is coming from in case you didn't realize it. It is a response to a Spring fan-boy blithely claiming "Spring IoC has everything CDI has", followed by support of the statement from SpringSource itself. Frankly, I rather would not have repeated it here, but had little choice but to respond to the other troll with personal attacks, vague statements and no real point.
I *do* find it irritating when Spring fan boys make FUD statements about CDI/EJB/Java EE that I can't help but responds to given the hard work we've put behind it. I've also already stated why I find it disappointing why SpringSource didn't implement the CDI/Java EE 6 Web Profile despite our best efforts. Seeing things like "Spring 3.0 is Java EE 6 compatible" after that is downright shocking! To top it off, there's the uncalled for personal attacks, including your own latest gem. If you don't understand my response, perhaps it is because you've never created something you take personal pride in...

Understandably you don't seem to get my point.

You had a point? Let me see, you made half-baked, vague statements on both Spring and Java EE followed by an equally vague endorsement of PHP. That about cover it?
I've never been one to put up with any nonsense and I never will. If you think I'll be bullied by insults and personal attacks, think again....
Not so kind regards,
Reza

Its much easier and sensible to plug in with just what you need rather than taking the whole big fat JEE.

Albert.

Personally I don't think Java EE is that fat at all, but through the new profiles and modular implementations like Glassfish and Jboss, it's actually easier to remove what you don't need.
Plugging in stuff is only really easy if this is explicitly supported by your implementation. E.g. like apt-get in Debian. I don't consider manually adding a few dozen jar files with unknown shared dependencies from god knows where to Tomcat as "much easier and sensible". I've seen this kind of setup turn into a jar hell far too often. It might sound like a good idea when you're initially composing your stack, but trust me, a few years down the road and you'll seriously start to regret such decision.

Springsource supporting JEE is not a function of just merit, we all know that.

Wow, all hail the all-knowing master representing all IT workers in the world!!!
So enlighten me, why do you think SpringSource supports Java EE? By their own statements, it is about technical merit and that's certainly the way I see it, particularly of @Schedule and @Async added in EJB 3.1.
Sorry but as I see it, you anti-Java EE bigotry is showing...
Not so kind regards,
Reza

Wow!
You need to take a chill pill!
So can you go back to my posts and tell me where do you see a "Personal attack"? This is what is being done by you.
FYI, i'm NOT a spring fan boy as you claim. I have used both and found spring far more benefiting and expressed my opinions accordingly. Whats wrong with that?
"If you think I'll be bullied by insults and personal attacks, think again...." What?

A subtext thread could continue - but this line of thread has accomplished what it can accomplish. Can everyone count to ten and try some meditative breathing excercises? Ok, good. Now let us talk about Spring and Java EE6 and so on. It is appreciated. Play ball!

Have you taken a look at Java EE 6/CDI/EJB 3.1 lately (even SpringSource supports a majority of EJB meta-data, now including EJB 3.1 @Schedule and @Async)? What you are saying about Java EE simply has not been true for quite a few years and frankly is quite unfair. And I think Java EE 5/6 is quite easy to develop/deploy with (and so is Spring to a slightly lesser degree). Now, I am not saying PHP does not have merits, clearly it does have a very important role. In fact, Resin provides a Java-based PHP implementation that runs on top of Java EE.

Cheers,Reza

Reza,

Springsource supporting JEE is not a function of just merit, we all know that.

Yes i have seen the changes u mentioned, though not as comprehensively. We can all quote these specifics for the sake of arguments, but the bigger picture doesn't prove it. Its much easier and sensible to plug in with just what you need rather than taking the whole big fat JEE.

Albert.

+1. No idea why one would want to use the bloated JEE rather than only what you need in a light-weight, highly performant, container such as Jetty or Tomcat.

Quite interesting when Spring meets Java EE/J2EE.
(Pure) Java EE guys and Spring guys both have their favorite platforms - Java EE guys just use Spring, Spring guys use Spring, that's fine. It seems that Java EE applications have to reply on Spring to simplify development has finished. Java EE applications can using Java EE only technology without help of Spring since Java EE5. With Java EE6 Spring is not required further. Thanks Spring's help in the dark old EJB ages!
But lots of Spring guys ignore a basic fact, that most Spring applications actually are also J2EE applications, just without EJB. (Remember? Expert One on One Development Enterprise Applications without EJB, the theory of Spring Framework). Spring applications still needs JDBC, JTA, JPA, JMS, Servlet/JSP API ..., just no EJB. And Spring application still need to be deployed to a J2EE web container, Tomcat or Jetty. It seems that some Spring fan boys don't well known what is J2EE/Java EE, they think Java EE is EJB.
I have used old J2EE and Java EE 5, and I have also used Spring. Spring is a nice framework, it's just that J2EE + Spring standard combination has been finished. Java EE has all the functionality now that the old J2EE + Spring can supply. As a trend, Spring is finished, it has done it's historical task. Unless Spring Framework did some revolutionary change and compatible with Java EE 6 completely.

But lots of Spring guys ignore a basic fact, that most Spring applications actually are also J2EE applications, just without EJB.

Of course - every technology has its fanboys. I'm sure there are Hibernate users, who haven't written single line of JDBC code. But still Hibernate uses JDBC just like Spring uses or makes JavaEE easier, more portable and more elegant (of course JavaEE becomes elegant by itself from edition to edition).

... it's just that J2EE + Spring standard combination has been finished. Java EE has all the functionality now that the old J2EE + Spring can supply. As a trend, Spring is finished, it has done it's historical task.

I'm sure Java EE doesn't have all the functionality of old J2EE + Spring. Java EE says little about security (only about its declarativness and JAAS which isn't actually part of JEE) and Spring Security is mature, real-needs driven product.
Also - "Spring" is not JavaEE competitor - it's not consisting only of JavaEE "counterparts". It has great resource management classes, great real-need util classes (String, Generics, Reflection), it has great MVC framework (JEE doesn't have MVC framework, only pure servlets, JSP, JSTL and JSF(2) which is not MVC framework).
And remember about all side-projects - security, webflow (which integrates, not competes with JSF), integration (great product! - and don't tell me about JBI, which, by the way is not JEE), WS.
regards
Grzegorz Grzybek

I'm sure Java EE doesn't have all the functionality of old J2EE + Spring. Java EE says little about security (only about its declarativness and JAAS which isn't actually part of JEE) and Spring Security is mature, real-needs driven product.

Sure, you have a point there. There are definitely bits and pieces in both frameworks that are superior to their counterparts in the other framework. Security might indeed be given some more work in Java EE. Although I'm not the one working on security in our Java EE app, I do remember some remarks from the guy working on it about some of the mismatches in it like JAAS using the term subject, while Java EE uses principal. Silly little thing.
Also, form based authentication doesn't really seem to have been updated for years and is still very much tied to plain JSPs. JSF with Facelets, which are now the default view technology for Java EE, still doesn't have out of the box support for this. Creating a form based authentication JSF component is not -that- hard and there are some available on the net, but it's still a step that shouldn't be necessary. Also the fact that form based declarative authentication only kicks in when accessing a restricted resource is often seen as problematic.
Java EE surely could need some improvements here. On the other hand, we do have the Authentication SPI for Containers (JSR 196) now, so maybe this will bring something good :)
On the whole I do like to note -again- that I'm definitely not anti Spring. I'm revolting against these mindless zombies that try to let others believe that Java EE is a completely bloated afair and is completely dead, has no future and is totally eclipsed by Spring, who's applications run on a 6.1 MB Tomcat without needing anything else. This is of course not true. I think the genuine hard working 'normal' Spring fan also knows this. Java EE and Spring are both capable frameworks, each with their own strengths and weaknesses.

(JEE doesn't have MVC framework, only pure servlets, JSP, JSTL and JSF(2) which is not MVC framework)

I'm not too sure about that. In my book JSF most definitely is a MVC framework ;)

I'm not too sure about that. In my book JSF most definitely is a MVC framework ;)

When you mean that FacesServlet is controller, than it's true. When you're thinking about components - it is not. JSF is Java's answer to ASP.NET (quite good in some points). And ASP.NET MVC is .NET's answer to Java's web frameworks descending from Struts 1.

On the other hand, we do have the Authentication SPI for Containers (JSR 196) now, so maybe this will bring something good :)

That's IMO the problem with JavaEE. Can you sell this specification? Can you create a product with it? You need an implementation. Simple example:

Though not all containers on which metro can run today support JSR 196, the idea is that as more and more containers adopt JSR-196, integrating the metro webservices stack with those container would become easy.

This is the problem - when more and more containers. So JSR 196 apps are not portable. Spring apps are.
regards and Merry Christmas!
Grzegorz Grzybek

unfortunately you and few others keep making an attempt to hijack it and make it look like we are back in JEE vs Spring war

Look at the third post of the thread. As it seems, I posted reasonable question which has nothing to do with 'bloat', but apparently people from 'your camp' have the need to flag anything that questions SS as 'big bad vendors'.

No, between Java EE servers.
Spring is built around Java EE, to be clear - Spring makes:

J2EE much easier

JEE easier because JEE became easier (not less powerful - just opposite)

This thread is about "Spring vs. Java EE". For me there is no such battle. Once again about my application which runs and is developed since 2004 - if it were built with "pure" Java EE (and I have a feeling that someone's trying to convice "Spring fanboys", that since 10th December 2009 pure Java EE is all they need instead of their legacy and proprietary framework-thing) it would be unmaintanable and untestable. Of course we could rewrite it from J2EE 1.3 to 1.4, then 5, then 6, but we're not being paid for such work.
Thank to Spring Security (and I think we're clear Java EE is not complete in this field) our application doesn't require:

few hundred clicks to configure LDAP role mapping in WebSphere

external configuration (conf directory) in JBoss

custom Realm in Tomcat

It just works in all these containers, role mapping configuration is part of WAR and stored with the project in Subversion.
This discussion is mostly about Weld - I'm sure it's good and modern product that wasn't built in some ivory tower. But Spring Security is working with Spring Framework's DI container out of the box. You got me - I'm in vendor lock-in. Tell me than - are there other CDI implementations?
In tutorials everything looks great - but tutorials don't show what problems will you have in 3 or more years.
I'm aware that entire JavaEE evolves. So does Spring.
And finally - I personally (I think other Spring "fanboys" also) am sure that there is no choice between Java EE and Spring. Either you use "pure" Java EE and don't import anythink beyond javax.* or you think in terms of real problems and real solutions and you use anything that simplifies your work and makes it more transparent, auditable and documented.
Think about Spring's reference documentation as it's "specification" - it's not really that different from Weld and CDI.
One more thing comes to my mind - JSR 315 (servlets) is good - but are you purists use pure servlets and deal with pure servlet requests and responses? Or do you use the only approved JSF2? I, when it's needed, sometimes use Spring MVC's SimpleFormControllers, sometimes annotation driven controllers, sometimes JSF (yes), sometimes "non-standard" (but working well) implementations of org.mortbay.jetty.Handler. Is it Java EE? Maybe not pure Java EE (TM) but surely it's Java for the Enterprise.
regards
Grzegorz Grzybek

I'm not too sure about that. In my book JSF most definitely is a MVC framework ;)

When you mean that the FacesServlet is a controller, then it's true. When you're thinking about components - it is not.

The FacesServlet is indeed the controller in JSF. A general, abstract kind of controller if you like, which you declaratively influence via EL based method bindings and navigation rules. If you want though, you can take controller matters more into your own hands by means of Facelisteners and/or explicit control code in your backing beans (like reading GET parameters and emitting redirects based on some outcome programmatically).
JSF 2.0 has vastly improved this area, especially in the way it's now able to handle GET parameters and by allowing powerful EL combinations to be used in the navigation rules.
I'm not really sure what you mean with "... components - it is not". The view part of JSF is very much component based. Better yet, the view part in JSF is actually its biggest strength. When we were still arguing about the strengths of Struts vs JSF, it was common to state that Struts had a more powerful controller, while JSF had a more powerful view, being completely component based, with a component tree, compositing, event queuing on components, etc.

On the other hand, we do have the Authentication SPI for Containers (JSR 196) now, so maybe this will bring something good :)

That's IMO the problem with JavaEE. Can you sell this specification?

Not really. The spec is free to download and free to implement. Just go to the JSR page and click on download. There is no cost and no registration required. This is maybe unlike some other spec documents like the much used SQL (from wikipedia: "The SQL standard is not freely available. The whole standard may be purchased from the ISO as ISO/IEC 9075(1-4,9-11,13,14):2008")

Can you create a product with it? You need an implementation.

Indeed you do. That's why those specs always have a reference implementation (RI). Despite the fact that the name may suggest otherwise, reference implementations are actually often production quality. In this case, Glassfish has already implemented it. Judging from their roadmap, Jboss AS will in about half a year.
But like I said *maybe* this will bring something good. It's a fairly new spec release, with a somewhat shameful history. Originally we were supposed to have this in late 2003, well in time for the J2EE 1.4 release and it should have blossomed fully in Java EE 5. Unfortunately this didn't happen. A good 6 later, it is now finally here and it's an official part of Java EE 6.
Since security is not my field of expertise, there is little else I can comment about this. I just hope that something good will come out of it.

This is the problem - when more and more containers. So JSR 196 apps are not portable.

Not yet indeed. There is only 1 Java EE 6 implementation, but fear not, many are on the horizon ;)

Spring apps are [portable].

Portable where? In Spring?

No, between Java EE servers.

As I somewhat jokingly and sarcastically explained above, this is technically true, but this really does also mean that Spring is thus portable "In Spring".
I could just a well say that a Java EE implementation is portable between Java SE VMs. Namely, I would just store my app inside the Jboss deployment directory, and would then consider this combined whole "my application". This application can then be deployed onto any JVM running on any server. Technically, the JVM doesn't distinguish between running Jboss, which on its turn runs my application and just running any application. For the JVM, Jboss itself is also 'just' an application.
Technically I'm right with this, but of course in practice this is not how we think about deployments.

Continue avoiding Sun / JEE, they employ unbalanced psychopaths that misinterpret and nitpick mundane details of release notes and hijack messageboards and very poorly attempt to slander the framework that rescued Java from death and obscurity whilst touting how well they copied said framework five years too late. Keep fortune 500 company I work for on the path of Sprig / or C# & .NET.

Continue avoiding Sun / JEE, they employ unbalanced psychopaths that misinterpret and nitpick mundane details of release notes and hijack messageboards and very poorly attempt to slander the framework that rescued Java from death and obscurity whilst touting how well they copied said framework five years too late. Keep fortune 500 company I work for on the path of Sprig / or C# & .NET.

Ahh, ignorance is bliss. I like your whoever-disagrees-with-us-is-evil-since-we-are-good-since-we-say-so type of tactic.
Also note the third post of this thread, 'one-of-you' hijacked your own thread.

It's so funny to see people comparing the size of jars. Java EE contains many other features as well. So just compare the core of these two IoC will be ok. Just comparing the weld-core with spring-core will be fair.
Comparing spring to Java EE is absolutely unfair. Spring contains all the features in Java EE? Absolutely not.

TechTarget provides technology professionals with the information they need to perform their jobs - from developing strategy, to making cost-effective purchase decisions and managing their organizations technology projects - with its network of technology-specific websites, events and online magazines.