From Spring to Java EE 6


News: From Spring to Java EE 6

  1. From Spring to Java EE 6 (75 messages)

    I recently worked on a quite complex project mixing many Java EE 6 technologies (such as JPA, JAXB, JMS, JTA, JAX-RS, etc...). For productivity and planning reasons, the prototyped application was designed as a standalone pure Spring application. When the development of the real application started, we re-challenged our initial choice (i.e. Spring v3) and analyzed the interest of switching to a Java EE 6 app server like GlassFish or JBoss. This finally ended up in two major questions:

    • can we do in Java EE 6 everything we can do in Spring ?
    • can we do that as easy as in Spring ?

    Well, I would say that, globally, the answer is: yes we can !

    Read more at :

    Java Code Geeks : From Spring to Java EE 6

    Threaded Messages (75)

  2. From Spring to Java EE 6[ Go to top ]

    Interesting article.

    Only one point was miss: what about testability?

    Spring based applications are easly testable, is it the same thing with J2EE6?

    My personal answer is not, only using Jboss with Arquillan you have an agile test environment, otherwise not.

    My personal experience with Glassfish was not good: it was a nightmare to try to use the Embedded container in order to test some ejbs.

    On the other hand with Jboss7+arquillan the story is much different.



  3. From Spring to Java EE 6[ Go to top ]

    CDI based projects like Arquillian/Seam/CODI are as much a part of the Java EE ecosystem as projects like Roo, Mule or AppFuse are to the Spring Framework.

    I've done GlassFish (and Resin) based testing with and without Arquillian with no significant problems. Slide deck and example code is here for anyone to try: -- presentation titled "Testing Java EE 6 Applications: Tools and Techniques".

    Questions, comments, concerns on embedded GlassFish can be posted here:

  4. From Spring to Java EE 6[ Go to top ]

    I don't know what was the problem, but we could not make GlassFish Embedded work.

    We read GF documentation, but we cannot use the Embedded to test trivial Stateless session beans.

    On the other hand, jboss Arquillan is ready to be used with complicated configurations.

    May be we are not GF experts..but at the end of the day we are migrating from GF to Jboss.

    And teest is only one reason.



  5. From Spring to Java EE 6[ Go to top ]

    I would advise you to post questions on the Arquilllian forums. I've used GlassFish with Arquillian myself and know people that use it in production very effectively (GlassFish was actually one of the first servers Arquillian built support for). That being said, JBoss is and always has been a good choice too.

    If you want, you can email me the problem and I'll be happy to look at it.

  6. From Spring to Java EE 6[ Go to top ]

    Thanks for posting this. There were two related presentations in JavaOne this year. The first is here: It is titled "Migrating Spring Applications to Java EE 6". Here is the second: It is titled "Java EE and Spring Framework Shootout".

  7. False Dichotomy[ Go to top ]

    The choice in the comparison is false: it's not either/or

    Java EE is a collection of APIs with various implementations available out there that can be mixed and matched with your preferred container (Tomcat, Spring, full Java EE Server).

    So I'm assuming what you swapped from the prototype to the real project was the Spring container for CDI/EJB since using the acronyms you mentioned (JPA, JAXB, JMS, JTA, JAX-RS) is not materially different whether it's Java EE 6 or Spring.

    Personally, I think the difference is small between Spring and Java EE 6, so pick the one you prefer and stick to it. I also think it would be nonsense to change a working system from one to the other as I don't see any big win for a slight change in flavour.

  8. RE: False Dichotomy[ Go to top ]

    Indeed, even if there exists an obvious overlap, both technologies are certainly not exclusive (that is what I mentionned in the conclusion).

    According to me, the biggest difference is that Spring is *also* an integration framework; you have plenty of ready-to-use (with some minimal config) classes, templates, etc.. hiding the complexity of the libraries/frameworks you want to use. Think for instance about the OXM module (abstracting the marshalling services that are common to Castor, JaxB, and XStream); or about a seamless integration with a scheduling engine (like Quartz). You don't have that kind of things in JEE...

    So it may still make sense to combine JEE *AND* Spring...


    Bernard Ligny. 

  9. RE: False Dichotomy[ Go to top ]

    Think for instance about the OXM module (abstracting the marshalling services that are common to Castor, JaxB, and XStream); or about a seamless integration with a scheduling engine (like Quartz). You don't have that kind of things in JEE...



    @MessageDriven(activationConfig = {@ActivationConfigProperty(propertyName = "cronTrigger", propertyValue = "0/30 * * * * ?")})
    public class DatabaseObserver implements Job {


    I don't undertsand the problem of using of JAXB or any other framework with JEE, I'm sorry.

    The right question would be a bit different: Will Spring have all the capabilities JEE provides?
    Let's take scalability and HA as an example.


  10. RE: False Dichotomy[ Go to top ]

    >> I don't undertsand the problem of using of JAXB or any other framework with JEE, I'm sorry.

    That is not a problem at all. What I wanted to say here (with the OXM example), is that Spring has identified and abstracted the common services that you find in available OXM librairies:

    public interface Marshaller {
    void marshal(Object graph, Result result) throws XmlMappingException, IOException;
    public interface Unmarshaller {
    Object unmarshal(Source source) throws XmlMappingException, IOException;

    This concretely means that you can for instance switch from JaxB to XStream simply by changing the marshaller implementation class in the config file:

    private Marshaller myMarshaller;

    <bean id="myMarshaller" class="org.springframework.oxm.xstream.XStreamMarshaller">
    <bean id="myMarshaller" class="org.springframework.oxm.jaxb.Jaxb2Marshaller">

    In Spring MVC module, you have the same kind of abstraction with the possible view/templates, allowing you to easily switch from Velocity to Freemarker...

    But that's not a reason to claim that Spring is "better" than JEE ;-)
    After all, using XStream and Freemarker in a JEE app server is not that complicated...

  11. False Dichotomy[ Go to top ]

    Not sure what comparison you were referring to specifically, but in ours we cover the case of using Spring/Java EE together and analyze when it makes sense/for whom.

  12. Real Application[ Go to top ]

    In the trviial, carefully selected examples it looks like they are similar but in the real world....

    1. Spring Data's JPA support will allow for a much simpler JPA implementation and alot less code

    2. Lokking at the REST service, it would probably need security. Correct? Spring Security is very powerful. What would you consider the equivalent in JEE 6

    3. The web service has to do something useful.. Spring Integration could accomplish your bus needs without any code!

    4. If you had to add more advanced JMS features like JMS connection caching, how does JEE 6 support this out of the box?



    I can go on and on... Java EE 6 is still well behind Spring 3. Spring is more much more than the basic examples outlined here and has a very rich set of libraries (Spring Integration, Spring Batch, Spring Security, Spring Data, etc.) that go well beyond JEE6.


    My 2 cents!



  13. Real Application[ Go to top ]

    I think you need to look at the Java EE ecosystem a bit more closely/update your skill set.

    Some answers:

    * You can either use JAAS based container security or Seam Security.

    * You can easily use Java EE friendly bus solutions like JBoss ESB (there is even a Seam Module for it), Oracle Fusion SOA Suite, etc.

    * Java EE application servers do JMS connection pooling out of the box (have done so well before Spring).

    * Take a look at javax.batch for Java EE based batch processing:

  14. Real Application[ Go to top ]

    * You can either use JAAS based container security or Seam Security.

    * Java EE application servers do JMS connection pooling out of the box (have done so well before Spring).


    JAAS or Seam Security are by no means as simple or powerful as Spring Security.

    Likewise, Spring JMS support is by far a superior solution compared to the JMS support that application servers provide.

  15. Re: Real Application[ Go to top ]

    Perhaps Reza, you should consider updating your skill set as well. Your talk from JavaOne repeatedly compares current Java EE features to Spring implementations that look like they were written for four years ago. Next time you decide to do a "shootout" perhaps you should at least compare apples to apples and perhaps even invite the person you are shooting at to participate.

    I also like how you recommend javax.batch to the poster....where can I get the code for that again? Oh yes, it is a proposed spec with no code to download and none expected until mid 2012. Spring Batch is a mature, established and productive solution with thousands of real production implementations. The same can be said for other common development problems for today's apps like OAuth security, social media integration, combining noSQL and relational data stores, cloud deployment, etc. Spring provides solutions for all of these areas of current application development while "Java EE Experts" spend their time blanket posting on web forums. 

    I think the answer is clear, if you want to build flexible, testable, portable applications that address today's enterprise demands you can use Spring, or you can wait 12-24 months for Java EE to dilute it into a standard that is just enough different to be incompatible and then wait another year for the application servers to actually implement it.

    Yes, I do work for SpringSource so feel free to dismiss my statements as biased, but I'll take my comfort in the millions of Spring developers that recognize the truth in my statements.

  16. Re: Real Application[ Go to top ]

    Firstly, please be specific about your feedback on the shoot-out. We covered the latest features in Spring 3.1 (including beta features) as well as the latest in the Spring ecosystem. And yes, I did ask for specific feedback on the content from someone in SpringSource and their feedback was incorporated as we best saw fit.

    Secondly, javax.batch is largely based on the WebSphere Compute Grid--which is a very mature product. You are awfully vague about it, but I am assuming you are trying to claim that CDI based solutions like Seam are not mature/usable. In reality while there are definitely Seam modules in alpha/beta phases there are also ones that are production ready and quite usable (I did a Seam 3 demo with them myself recently). As to your equally vague/FUDish remarks about Java EE implementation pace, here is a resource that details available implementations: It doesn't even cover the recent announcement of WebLogic 12c. I'll also cover the validity of some of these claims on an up-coming series focusing on anti-Java EE myths/FUD.

    As to your purported bias, I don't think it's necessary to comment on that since I am not as good at/keen on personal attacks/FUD/negative marketing that have nothing to do with technology as SpringSource employees appear to be :-).

  17. Spring Batch is bloated design[ Go to top ]


    In the last two years alone, I worked in three of the top banks in the country and used Spring Batch extensively. For each batch job that I had to write I ended up with upto 10 classes. Here is a sample listing of SPRING CLASSES:


    Apart from the above, 75 lines of configuration need to be written to "wire" the above SPRING beans to Pojos. 

    All of this for ONE batch job. And please note, no business logic has been written yet!

    If you have 25 batch jobs (typical in a large financial company), can you imagine how many Spring classes I need to write? 200 SPRING CLASSES and 2000 lines of configuration.

    If Spring knew a little about Java 5 annotations, such design bloat would never have creeped in the first place. Unfortunately, there are not many sophisiticated opensource Batch frameworks so I'll give Spring some credit here, but is this good design? I don't think so. Most developers use Spring not because it's good, but because they've been told to by their "architects" or "development managers."

    I have only talked about Spring Batch and I could provide other examples of Spring MVC and Spring Webflow which fail to address business problems in clear, concise manner.

    Folks, I'm not trying to attack Spring. In fact, it is what I do mostly in my consulting assignments (whether I like it or not). But I am open to JEE, Play!, or even RoR as an alternative to solving problems. As a mature opensource company, I except Spring to behave in an open, collaborative manner, but it seems to me -- with the recent acquisition by VmWare -- Spring's focus has been elsewhere: Create FUD about its competitors.

    That's unfair.

  18. Real Application[ Go to top ]

    "You can either use JAAS based container security or Seam Security" - Would love to see see a comparison with Spring Security. I think you will be quite suprised at it's capability

    "Take a look at javax.batch for Java EE based batch processing:" - Hmmm... Sounds quite similar to what Spring Batch already has available. Could you point the readers to a production worthy implementation?

    "You can easily use Java EE friendly bus solutions like JBoss ESB (there is even a Seam Module for it), Oracle Fusion SOA Suite, etc." - There's nothing friendly about Oracle Fusion SOA suite. I have plenty of experience with it. Would love to see a post detailing running Oracle Fusion running on Jboss server! Not very portable or EE friendly


    Anyway.. I'm off to brush up on my skill set.







  19. Real Application[ Go to top ]

    I have very extensive experience with Spring Security/Acegi. I am far more impressed by the usability of Seam Security or the Resin Security Framework: If you want a comparsion, I suggest doing one yourself and blogging about it. I am sure it will be generally helpful.

    I already did point out a very mature Java EE friendly batch processing implementation that javax.batch is based upon. It's likely to be the reference implementation. I have also personally implemented batch processing solutions based on Flux/EJB/MDB/JMS/Java EE 5.

    I have used Oracle Fusion SOA Suite, BEA AquaLogic and WebSphere ESB. Very frankly, I think they are far more robust and easy-to-use than JBoss ESB, Mule, Spring Integration, etc. The point is that there ae plenty of service bus solutions that integrate with Java EE via CDI or JNDI/EJB -- both commecial and open source (to correlate with your functional needs/budget).

  20. Useless[ Go to top ]

    JEE 6 is a good improvement no doubt, but such movement is really not worth the expense and adventure in recession. I guess this is sponsored by some open source JEE server / framework vendor. Spring is still a better choice than JEE reasons already given so I will follow DRY.


    Cheers ...dhrubo

  21. Useless[ Go to top ]

    None of the resources qouted thus far is sponsored by a vendor but rather highly individual initiatives driven by real world experience. Suggesting otherwise is not just incorrect, it is downright unethical.

    One could argue Java EE is more in line with DRY/KISS far more than Spring is or ever was (indeed that's a main point in our comparison in  particular).

  22. Really?[ Go to top ]

    How easy or difficult it is to load a properties file in JEE?

    Is there a PropertyPlaceHolder equivalent there?

  23. Really?[ Go to top ]

    Good - finally a Spring proponent that actually sticks to the technology and asks smart questions rather than trolling flame wars :-). Take a look at Seam Solder resource/property loading:

    Also, EL is being enhanced in Java EE 7 to load property file entries directly. Follow Java EE 7 progress here: (the best way to be part of the solution rather than being part of the problem).

  24. Really?[ Go to top ]

    Thats good news but when will JEE 7 see the light? What do I do in my prjects now? So as someone mentioned here JEE is about taking in Spring features and diluting it and then waiting for ages for features to be incorporated in app servers.


    BTW - With my limited knowledge about SEAM - Isnt SEAM another framework - because JBOSS folks had nothing to counter Spring and TOMCAT combo?


    IMHO - Unless you are part of the problem you will never feel the pain to seek solution :)

  25. Really?[ Go to top ]

    None of the resources thus far have talked about Java EE 7 features, just Java EE 6 and the CDI based ecosystem -- that's all. Seam 2 was a framework -- Seam 3 is not. Seam 3 is simply a set of CDI plugins. Read about CDI plugins here:

    Anyway, Java EE 7 is due to be released second/third quarter of next year (or maybe sooner depending on some key decisions).

  26. beware of @Singleton[ Go to top ]

    Hi! Small addition: don't use @Singleton at all. It's really underspecified. What do you expect from a @Singleton? 1 instance per JVM? 1 instance per EAR? 1 instance per WAR? 1 instance per cluster? It's just not defined, thus you better use @ApplicationScoped (which means 1 per WebApplication) LieGrue, strub
  27. From Spring to Java EE 6[ Go to top ]

    In the Stateless bean, the annotations @TransactionManagement(value=TransactionManagementType.CONTAINER) and @TransactionAttribute(TransactionAttributeType.REQUIRED) can be removed, as these are both the default for @Stateless.

  28. From Spring to Java EE 6[ Go to top ]

    Another article about Spring vs JEE:

  29. From Spring to Java EE 6[ Go to top ]

    Thanks for posting this. I wasn't aware of this particular anaysis -- it looks pretty good and the author seems competent/responsive.

  30. From Spring to Java EE 6[ Go to top ]

    Thanks for posting this. I wasn't aware of this particular anaysis -- it looks pretty good and the author seems competent/responsive.

    BUT: In most projects you do not need this flexibility or power. If you do need it, then use Spring, not JEE – of course!

    Indeed - very competent :)

    Everyone writes the same comments all over again, so it's my turn.

    Reza - you're talking about JavaEE 6 and 7, about javax.batch. Great. The reality however is often "666" - it means: WebSphere 6, Internet Explorer 6, 6 weeks to complete. I wonder where there's place for JavaEE 6? Thank God WAS6 works on JDK1.5! And also - if someone would ask - it's not that bad - WAR deployed on this "platform" contains Spring (Security, Framework, WS, LDAP) in its newest versions - e.g. 3.1.0.RC2.

    With WAS7 it's still not better. I'm working on a (very) large project with WAS7 and WPS7. But recently the beautiful JavaEE5 programming turned into Wireshark sessions in quest for hunting WebSphere/CORBA/IIOP/EJB/JTA/FileNet bugs - very educational!

    I know JavaEE6 is good, JavaEE7 is better, JavaEE8 is the best and JavaEE9 is heaven's sent - but there are some institutions which won't upgrade their WAS6 ever.

  31. From Spring to Java EE 6[ Go to top ]

    Frankly, that's your problem. There are plenty of good reasons to upgrade to Java EE 6 and there are plenty of people doing it :-).

  32. From Spring to Java EE 6[ Go to top ]

    Frankly, that's your problem. There are plenty of good reasons to upgrade to Java EE 6 and there are plenty of people doing it :-).

    Tell this to the Minister of ... (sorry - confidential...).

    And recently I had very good experience with JBoss 7 - I've even submitted a pull request to jboss-modules that allows JBoss 7 to be run on @#$ing WebSphere Client...



    Grzegorz Grzybek

  33. From Spring to Java EE 6[ Go to top ]

    Another example of cribbing when someone has valid logical reason. This is not an isolated case. Such cases are more than people keen on migrating to Java EE 6 from Spring investment just because one "rR" wrote a blog post. These are days of recession my friend and CXOs will think 1000 times before listening to bragging.


  34. From Spring to Java EE 6[ Go to top ]

    Like I said -- I don't seem to have any such problems. Clients that I work with are open to upgrading application servers for new applications. It's even easier with the cloud. It takes less than a day to spin up a new instance of GlassFish or JBoss on Amazon EC2.

  35. From Spring to Java EE 6[ Go to top ]

    Ok he is responsive and compentent because his frequency matches with yours. Let me put few links together - (Google has made our life so easy)

    "Java EE 6 might be a better foundation to build upon, but it's certainly not going to replace frameworks."

    Well Matt Raible knows a thing or two about Enterprise Java I guess.

    Oops I found one more -


  36. From Spring to Java EE 6[ Go to top ]

    As others already pointed out, Matt's analysis completely missed the point about CDI pluggable solutions like Arquillian, Seam and CODI. The second one comes from a SpringSource employee and is full of a bunch of outdated anti-Java EE FUD that was easily dealt with (in the discussions of the blog post itself) :-). Sorry -- but you'll need to try a little harder...

  37. From Spring to Java EE 6[ Go to top ]

    The point is not about pluggable blah blah. The point is both are frameworks. Its a question of where you want to load yr bag of jars. I guess you are so hot as most people here are not talking in your tune your now making personal attacks.

    First learn to have respect, its a global forum. I dont want to say that you are ignorant about Spring.But cribbing does not take us anywhere. Its all about dollars enterprises want to invest. Just because ESPN has done something will never mean BBC will do the same.

  38. From Spring to Java EE 6[ Go to top ]

    Huh? Point out where I have personally attacked anyone? All I did is point out where you are wrong and are quite ignorant about Seam/Java EE 6. Seam 2 was a framework -- Seam 3 is just a collection of CDI plugins. Take a look at the description for Seam 3 here: You won't even find the word framework anywhere -- that was the whole point of standardizing CDI.

    Blatanly failing to admit mistakes/ignorance doesn't exactly engender respect :-).

  39. From Spring to Java EE 6[ Go to top ]

    full of a bunch of outdated anti-Java EE FUD

    --- this shows what you have said and what respect you have for others. I have already said I am igonarant about SEAM (collection of CDI or whatever) but whatever it is still a framework and not a server.

    There is nothing to admit mistake.

  40. From Spring to Java EE 6[ Go to top ]

    Look - no offense but you really should do a bit more research on this before making the type of statements that you did if you want to be treated with respect. Seam 3 is no more a framework than RichFaces or ADF Faces. It has no component model, does not sit on top of a lower level runtime and has no core runtime of its own (Spring does all of these, as did Seam 2). Seam 3 is just a set of CDI add-ons, much like Spring has distinct modules that add on to Spring IoC.

  41. JEE "by the book" in all the implementations that I have tried in the 3-4 last years is:

    - hard to debug

    - a nightmare to maintain and upgrade, from version to version or even maintenance for the same version

    - hard to test, forgot an Agile approach like TDD/BDD or similar flavors

    - slow runtime performance, sometimes really bad ; well, for some time critical stories Spring layer is slow too

    - expensive if you need to cluster / scale in general

    I am favor of a Spring implementation, eventually with some "flavors" for instance Spring Roo :) that is really cool as a RAD framework and convention over configuration approach.

  42. come on, you will not fool me again :)[ Go to top ]

    Interesting -- I have been doing Java EE 5 and Java EE 6 projects in the real world that contradict all of your above assertions as does the experience of folks like Adam Bien -- (not to mention the posters of this article/resources).

    As to RAD, Seam Forge/JBoss Tools enables the same for Java EE 6, just as seam-gen did for Java EE 5 (well before Spring Roo).

  43. come on, you will not fool me again :)[ Go to top ]

    Since you are insistent on speading this old FUD, here are some GlassFish/Java EE 6 success stories from JavaOne 2011: It includes Adam Bien, ESPN, etc. I am hoping to persuade some of my own customers to do similar testamonials. I am hoping at least the fellow from ESPN will speak at TSSJS 2012...

  44. come on, you will not fool me again :)[ Go to top ]

    Good luck. Your success will be 1:1000

    Keep us posted of your misadventures.!

  45. come on, you will not fool me again :)[ Go to top ]

    BTW, I have a project success rate of 100%, so try again :-).

  46. come on, you will not fool me again :)[ Go to top ]

    Really, now you really making me laugh and fall from my chair!

    IT project success rate of 100% unbelievable achievement, something for the museum for SURE.You are the only one with that success rate. Probably you work alone not in a team!


  47. come on, you will not fool me again :)[ Go to top ]

    Yep -- that's exactly my reputation and why I am an independent consultant in one of the most highly competetive indutries in one of the most industrailized parts of the world. And I am not alone -- take a look at Chariot Solutions: Thay also have a long-standing reputation for their execution success rate.

    Most recently, I finished executing on a project that everyone in the organization deemed impossible to achieve -- guess what I didn't use any Spring but just Java EE :-).

  48. come on, you will not fool me again :)[ Go to top ]

    Thats exactly what i meant. You are not a team player. You are an individual. You work alone and count your personal success. Not that of a team. The DOBB data is not for individual but for team.


  49. From Java EE 6 to Spring[ Go to top ]

    BTW - I have decided to now write a blog entry on Java EE 6 to Spring.

    You can suggest me an application that you want me to migrate. I will do so and see how easy (question of difficulty is out of the window).

    Is there a JEE 6 petclinic stuff?

  50. Re: From Java EE 6 to Spring[ Go to top ]

    BTW - I have decided to now write a blog entry on Java EE 6 to Spring.

    Great idea. Be sure to check out the new Github project for helping migrations:

  51. Re: From Java EE 6 to Spring[ Go to top ]

    On this point, Rick Hightower actually wrote a very useful CDI plugin to help the migration from Spring to Java EE (or using them together):

  52. From Java EE 6 to Spring[ Go to top ]

    Good - this means you'll actually need to write a Java EE application first -- something you clearly have not done :-). Make sure to post your blog here so I can giev it the feedback I am sure it will deserve.

  53. From Java EE 6 to Spring[ Go to top ]

    It is true, the last time I wrote an EJB was way back in 2004. Since them my life is full of pleasant breeze with Spring.

    Why unncessarily complicate life because one cribber wants to enhance sales of "EJB3 in Action"

  54. From Java EE 6 to Spring[ Go to top ]

    Funny -- my book sales count for less than 1% of my annual income and my consulting practice is completely independent of Spring, Seam or Java EE. Take a look here: Keep up the baseless accusations though -- it'll serve as an archive to your stupidity :-).

    At least you finally admitted you have no clue what you are talking about when it comes to Java EE. It's even funnier that you are actually proud of being ignorant :-).

  55. I've been a Spring and Hibernate user since 2004 (three more years of dev experience before that) and till date worked on over 9 projects. My dissatisfaction in Spring has led me to venture into simpler frameworks like Play! Framework, Lift, Django and Guice. However, given the choice between Spring 3 and JEE6, I would pick JEE6 for its simplicity, best of the breed standards, and productivty.

    Early this year I implemented a prototype stack for a client of mine in JEE6 and I was surprised with how easy it was to build a basic webapp with the most common configuration options. The ability to get it right "out of the box" wins me over Spring's inherent cluster-mess of sub modules and "integration" options. To me, Spring doesnt solve any problem but just gives you hooks to integrate. If you like to be in a kithcen and mix 100 soups, its probably a good fit. They overdo AbstractFactory, Strategy, and Template Patterns to a point where writing a simple extension becomes a pain point and non-readable.

    Consider, Spring Batch or Integration for instance: They have no support for annotation or event delagation model. What that means is if you have to write 10 batch jobs, instead of writing 10 pojo services, you end of writing 50 Spring classes (ItemWriter, ItemProcessesor, ItemReader, Listeners etc .,) and a 500+ line config file. This level noise can be eliminated if Spring folks understood how annotations work; that is, you don't need a class and an xml config to wire a method to your bean but you could simply annotate a method and let a post processor take care of it. 

    Even Spring transactons, for all its support and clarity, one still has to write them and maintain the configuration files where a JEE 6 continer can get away with it trivally, along with the 40+ jar files you need to maintain a maven or ant build. Some projects I worked, where part of the code is at offshorem, the code I see is spaghetti and because Spring doesn't tell you "how to write smart code" developers with lesser experience start dropping business concerns and write code that looks like a Spring this and Spring that, like spaghetti.

    Having lesser footprint, intuitive concepts like Context management, bean extensions, events built right into the framework with annotations and interceptors (not aspectJ) as a first class citizen, is a win, any day.

    In the end, my client decided to let go Spring and moved to JEE6 and Seam 3 with JBoss. The last I heard from them, they are very pleased. 

    True, Spring is still used widely in corporations. Same was true for EJB3 until 2005 :).

    I blogged some of my findings here on my blog, if you're interested.

  56. Well said - we need more folks like you to speak your mind :-).

  57. Just the second friend so someone is so happy.

    BTW I thought of writing a lot but its useless. I have useful work to do.

    @Reza -- I will surely seek your feedback when I find time to blog about JEE 6 to Spring migration because I always believe feedback is important good or bad and I am open to ideas and feedback. It opens up our mind. This was a good debate sans the bragging. Probably we should have compared stone to stone.

    @Priyatam - sorry but you need to go back and read more about the philosophy and rise of Spring framework. I can see that you too used a framework like SEAM to ease your life and not just an JEE 6 compliant app server.



  58. Does Spring even have a philosophy?[ Go to top ]

    @dhrubo -- Can you point me to the "philosophy" of Spring?

    Spring solves the same problems in multiple ways, sometimes overriding its own philosphy, and making it difficult for developers to follow ONE philosophy. Take for instance Spring MVC Vs Spring Webflow. Rather than merging the two concepts and providing a conversation scope, Spring addresed it by creating a whole new project. Now developers need to learn TWO frameworks instead of one; not just that they need to integrated that two, and, integrate with JSF or another view layer. Spring's reluctance to integrate with standard specs (JSF 2) on time makes it harder for to integrate as well.

    Also consdier Grails Vs Spring Roo. I've used both and IMHO, they both are trying to address the same space of rapid application development. Why did Spring buy out Grais in teh first place and start its own Spring Roo project? Nice, philosophy there.

    With the purchase of VmWare, it seems Spring is now more interested in Cloudhosting ...

    Spring doesn't have a philiosphy and that's the problem I have. With JEE6  -- not J2EE unless you've been sleeping since 2005 -- there is a SINGLE philosophy of managing dependencies and contexts and extending the with clearly defined extension framework, which btw is called Modular development.

    Can you point me to a design or a technical essay on how Spring solves modularity both at a framework level and application level? 

    The rise of Spring framework is another topic outside the merits of using a framework and that should not be debated if you want to have a technical discussion.




    Spring is the only company (other than Eclipse) to NOT VOTE in JSR299.

    I would've appreciated if Spring contributed in the JSR community rather than criticizing JEE folks with the same old argument that about J2EE (which everyone agrees as a failure).

  60. Does Spring even have a philosophy?[ Go to top ]

    Priyatam -Spring's philosophy was outlined in his book by Rod Johnson and it was more inline with J2EE's drawback.

    I agree with you to some extent. Post takeover things are diluted into too many thing. Also there are lot of overlaps in JEE and Spring as JEE matures (and seeks feedback from community) and incorporates the good principles from Spring, Hibernate et al and also drops where it was wrong. I have tried my hands on JEE6 on JBOSS and honestly its much more refreshing than grand old days of 2001-2004 (my period of tryst with J2EE before moving to Spring).

    I am looking at a possible trend change not so soon in JEE adaptation may be mid of 2013. But Spring due to its integration choices with tons of framework will still remain a good favorite of many who do need such choices. Thats its gift and may be its curse :)

  61. Huh? The more you post the less sense you actually make. What "bragging" are you talking about exactly?

    Everything I said here is absolute, straight fact or very honest (perhaps a bit too brutally honest for you) opinion.

  62. Software project success rate[ Go to top ]

    Interesting. This is just statical sampling, ground reality of success factor should be even lower.

    There is no mention of 100% success.

    My comment initially was not about success of a brilliant individual or success of projects, rather success of convincing enterprises into migration from one tech stack to other. But when mind is shrouded by anger as others are not easily buying into your logic we tend to overlook such things.

    I hope the dobbs stats are just revealing "statistics are like mini skirts!" :)


  63. Software project success rate[ Go to top ]

    Yet another nonsensical post that has no point whatsoever :-). You are the one claiming that "my projects will fail because I use Java EE". You opened the door to my telling you exactly how off-base you are. Now you are whining?

  64. Software project success rate[ Go to top ]

    I am certain you need to check your lens power. Where did i write or claim "my projects will fail because I use Java EE".? Just point out. Calm down man. Enjoy the weekend.

  65. Software project success rate[ Go to top ]

    Ok now the thumb rule is whatever link or words RR says is word of GOD. Whatever others say or post is useless. No more comments from me as there is no point in discussing with snobbish, arrogant people who only know to crib and bark

  66. Please stop this (futile) war[ Go to top ]

    Come on guys ! How old are you ??? I am fed up with your "No, this isn't true, *we* are the best !"

    When will you be able to understand there is a way to love *both* Spring and JEE(6) ?

    When I wrote my article on JavaCodeGeeks, it was not at all to convince you to migrate from Spring to JEE6, nor to claim that JEE was superior to Spring...

    It would be completely stupid to always, systematically take the Spring or JEE option each time you start a new project. We are paid to build solutions satisfying our clients and taking account of many external parameters (eg expertise of dev team, legacy system/technos/applications with have to interface with, scalability and performances issues, position regarding the open-source, etc...). Sometimes Spring is more appropriate, sometimes not...

    But what I very clearly see is that there are (at least in my country ;-)) more and more companies that are planning to come back to JEE after some Spring years...

    And that's what my article was all about...

    <end of story>

  67. Please stop this (futile) war[ Go to top ]

    Yes it can happen for sure, if JEE releases are fast, focused with good documentation.

    I was an ardent fan of J2EE and took my own time to shift to Spring world.

  68. Please stop this (futile) war[ Go to top ]

    Like I said -- I'll address the "Java EE is slow" FUD in a separate article series. The long and short of it is that the JCP is a lot faster than other standards bodies like the IEEE or W3C. Moreover, the job of a standard is to allow ecosystem innovations to mature before standardizing them too quickly. Also, Java EE has always encouraged ecoystem innovations that developers can leverage when really needed.

    As to documentation, I think the official Java EE tutorial ( and Javadocs ( are very good by any standard, as are resources like the Weld documentation ( All of these resources are free and publicly available for anyone with a genuine interest.

  69. @Reza -- I AGREE. People who say JEE is slow haven't really worked on a real JEE 5 or JEE 6 project or integrated with extensions like Seam or Apache.

  70. Thanks a million -- as I mentioned before I really appreciate folks like yourself speaking out. There is nothing like end-user testimonials to fight FUD.

  71. I guess you guys know the art of twisting word.

    The opthamist really gotta business here

    No one said JEE is slow thats why use Spring. The point here is not of performance. Look how long it is taking for Geronimo or JONAS to make releases. Glassfish or JBOSS may be superfast in releases.

  72. Please stop this (futile) war[ Go to top ]

    I agree. Sometimes I think old, bad technologies like EJB2, Struts 1.x are very helpful. For example, my company is still using EJB2, Struts 1.2 and they write some stuff around EJB2, Struts which is very complicated. Thanks to its complexity, we need more programmers and that means more jobs are created. And that's good for the economy, isn't it?

  73. Please stop this (futile) war[ Go to top ]

    Well put -- and that's exactly what I've always said :-).

    That being said, I am not one to ever let anti-Java EE FUD go unanswered. The way I see it, the Java EE crowd does that way too much which is what motivated me to write EJB 3 in Action in the first place (I'm not talking about you -- writing the article took the kind of gumption I respect and wish there was more of).

  74. Very very interesting[ Go to top ]

    OK folks - only REZA thinks SEAM is not a framework. But JBOSS does that unfortunately. OK all the ignorant guys at JBOSS stand up and listen. You need to change your website URL and description about SEAM.

    Here is wat I saw -

    And the top headline says - 

    The Seam Framework - Next generation enterprise Java development

    Unfortunately I am unable to affix a screenshot.



  75. Seam 3 no longer a framework[ Go to top ]

    Please read the Seam 3 home page:

  76. Seam 3 no longer a framework[ Go to top ]

    Thanks for pointing out the obvious :-). It's really sad this individual does so little thinking/research before posting here. For the last time -- <i>Seam 2 was a framework, Seam 3 is not!</i>. Still don't get it? Ask the question in the Seam 3 forums and they'll be happy to explain it to you: