Discussions

News: Provocative Analysis: Spring Persistence or EJB?

  1. Solomon Duskis, enterprise developer and co-author of the upcoming book Spring Persistence 101, urges engineers interested in enterprise development to focus their energy on learning Hibernate and Spring, rather than EJB. He writes:
    Spring and Hibernate both have a tremendous demand, simply because they serve their purpose in a simpler way than EJB. The market place may not necessarily prove my analysis, but I'd say that it's a pretty convincing argument to learn Spring and Hibernate rather than EJB.
    Paul analyzed trend data for the last two years regarding job descriptions and the desired skills for applicants. Spring and Hibernate demand trends upward, while EJB demand has dwindled over the same period. Java is the overwhelming champion of programming languages in terms of development mindshare, but there are many camps in the Java universe. There are those who prefer adherence to standards and the sacred code of the JCP, while others prefer to engage practical solutions that just work, and who later may (or already have) become standards, like Spring, Mule, Hibernate, Wicket, and other technologies. What's your experience? Do you get job offers about EJB, Hibernate, or Spring? Where are you located? What kind of businesses demand your services? If you're hiring... what skills do you require of your enterprise developers? What are the trends in your industry?

    Threaded Messages (105)

  2. Based on my experience with Spring (versions 1.x through 2.x) versus EJB3, I prefer EJB3/JPA over Spring for persistence. I still use Spring as a service-layer bean factory in my EJB3 projects because I like the architectural separation that Spring provides, but I find that Spring (as a stateless framework) is a headache when it comes to managing your persistence context. OpenSessionInView can cause performance problems, and the alternative "service-layer transactions" approach is also error prone. You end up with detached entity graphs that must be re-attached (saved) with each request. Granted with extremely careful coding and configuration you can probably avoid LazyInitializationException, NonUniqueObjectException, et. al. but I find Seam/EJB3 much easier to use for persistence in Web applications. Ian Hlavats JSFToolbox - JavaServer Faces for Dreamweaver
  3. NonUniqueObjectException[ Go to top ]

    extremely careful coding and configuration you can probably avoid LazyInitializationException, NonUniqueObjectException
    I have faced both of this, but NonUniqueObjectException was realii a pain, sudhir jYog
  4. Silly comparison[ Go to top ]

    EJB 3.0 JPA is standardization of Hibernate. Comparing Hibernate to JPA is comparing implementation of the standard to the standard itself. Did author meant EJB 2.0? Bottom line is that EJB 3.0 / JPA is how we will use Hibernate. Spring is not nearly as useful in EJB 3.0 model as it was prior to 3.0 because almost everything is a POJO. But Spring still gives nice abstractions for configuration, testign and keeping sanity. But XML configuration files have to go, they are way to verbose and hard to follow. Annotations in most of the cases provide cleaner and simpler model. Having said that, I think most of us for today are still stuck with Spring/Hibernate because EJB 3.0 adoption by vendors is slow. But it's coming!
  5. blah blah blah[ Go to top ]

    blah blah blah blah blah blah blah, blah blah blah blah.
  6. blah blah blah[ Go to top ]

    BTW: I meant to reply to the main story and not Ian Hlavats' post.
  7. Re: blah blah blah[ Go to top ]

    Thanks. ;-) I was beginning to wonder if I had said something embarassingly stupid... Matt, I take it you don't find the article or the topic worthy of thoughtful discussion?
  8. Re: blah blah blah[ Go to top ]

    Thanks. ;-)

    I was beginning to wonder if I had said something embarassingly stupid...

    Matt, I take it you don't find the article or the topic worthy of thoughtful discussion?
    I do feel that there are pros and cons to both Spring and EJB3, and I think there are many points between the two are worthy of discussion. Your post is an example of a topic worth discussion IMO, and I encourage (and hope) that those discussions continue. I also share your feeling that Seam brings extra spice to the ejb3 mix. That being said I find this specific article irreverent, poorly thought out, and unhelpful as a whole.
  9. JPA is restricted sub set of Toplink, Hibernate, JDO No Criteria API in JPA, no QBE, not second level caching. So why restrict yourself why use JPA? IMHO Spring + Hibernate3 (both with or without annotations is best approach at the moment). I personally prefer to use annotations because it is easy to maintain the application. --Mark
  10. JPA is restricted sub set of Toplink, Hibernate, JDO
    No Criteria API in JPA, no QBE, not second level caching.
    So why restrict yourself why use JPA?

    IMHO Spring + Hibernate3 (both with or without annotations is best approach at the moment).

    I personally prefer to use annotations because it is easy to maintain the application.

    --Mark
    The JPA ri is a fine thing (but it also has its quirks) the main advantage over hibernate is, that it is just two (or nowadays) 1 small jar instead of 10-15 dependencies in hibernate. There are applications where the JPA ri does not cut it, but for many it is a perfectly viable way to go, if you need more fine grained control, something more sophisticated use hibernate or any other alternative, if you have a small app which needs an easy to deploy solution, jpa is more than enough. Besides that raw jpa is just a spec, which is also layered on top of most orm solutions, Hibernate implements JPA so does Toplink, I dont see any restriction, you can use jpa and still use fallbacks for more sophisticated stuff.
  11. The JPA ri is a fine thing ... the main advantage over hibernate is, that it is just two (or nowadays) 1 small jar instead of 10-15 dependencies in hibernate. ... if you have a small app which needs an easy to deploy solution, jpa is more than enough.
    I found QueryByExamples very useful both for complex both simple applications. JPA api is quite limited than Hibernate api, thus, why sould I use a poor library?
  12. mix and match[ Go to top ]

    Besides that raw jpa is just a spec, which is also layered on top of most orm solutions, Hibernate implements JPA so does Toplink, I dont see any restriction, you can use jpa and still use fallbacks for more sophisticated stuff.
    Yup. With JBoss JPA deployments you can: * use the EntityManager to manage hbm.xml mapped entities * use Hibernate Session to manage JPA annotated beans * use @PersistenceContext/@PersistenceUnit to inject a Hibernate Session and have the lifecycle of the session managed automatically by the EJB container (just as you would with a EntityManager) * You can overridde JPA annotated entity classes with a hbm.xml mapping
  13. JPA is restricted sub set of Toplink, Hibernate, JDO
    No Criteria API in JPA, no QBE, not second level caching.
    So why restrict yourself why use JPA?

    IMHO Spring + Hibernate3 (both with or without annotations is best approach at the moment).

    I personally prefer to use annotations because it is easy to maintain the application.

    --Mark
    For my money, I say go JDO if you can. If you have to, use JPA. Just my personal opinion, having used JDO pretty extensively over the last 5+ years (Kodo and JPOX primarily). As was pointed out, JPA is, at least in many ways, a subset of some of the others. It is also targeted squarely at RDBMS. While most people have no reservations with doing that, I personally wouldn't tie myself to any specific technology if I could get away with it. As far as implementations go, JPOX is tough to beat, given that it's licensed under Apache, full support for JDO 2 (2.1 pending), and significant support for JPA as well. One man's opinion...
  14. JPA is restricted sub set of Toplink, Hibernate, JDO
    No Criteria API in JPA, no QBE, not second level caching.
    So why restrict yourself why use JPA?

    IMHO Spring + Hibernate3 (both with or without annotations is best approach at the moment).

    I personally prefer to use annotations because it is easy to maintain the application.

    --Mark

    For my money, I say go JDO if you can. If you have to, use JPA. Just my personal opinion, having used JDO pretty extensively over the last 5+ years (Kodo and JPOX primarily).

    As was pointed out, JPA is, at least in many ways, a subset of some of the others. It is also targeted squarely at RDBMS. While most people have no reservations with doing that, I personally wouldn't tie myself to any specific technology if I could get away with it.

    As far as implementations go, JPOX is tough to beat, given that it's licensed under Apache, full support for JDO 2 (2.1 pending), and significant support for JPA as well.

    One man's opinion...
    Two. Guido.
  15. For my money, I say go JDO if you can. If you have to, use JPA. Just my personal opinion, having used JDO pretty extensively over the last 5+ years (Kodo and JPOX primarily).

    As was pointed out, JPA is, at least in many ways, a subset of some of the others. It is also targeted squarely at RDBMS. While most people have no reservations with doing that, I personally wouldn't tie myself to any specific technology if I could get away with it.

    As far as implementations go, JPOX is tough to beat, given that it's licensed under Apache, full support for JDO 2 (2.1 pending), and significant support for JPA as well.

    One man's opinion...
    It sounds like your advocating a non-EJB technology. [rant]How dare you!!!![/rant] You can build Spring applications that will happily work with either JPA or JDO. Spring will even let you easily mix and match without much trouble, if that's what your architecture calls for.
  16. It sounds like your advocating a non-EJB technology. [rant]How dare you!!!![/rant]

    You can build Spring applications that will happily work with either JPA or JDO. Spring will even let you easily mix and match without much trouble, if that's what your architecture calls for.
    Well, I am still waiting to understand the benefits of the EJB technology. Why should I giveup servlet/JSP+template+JDO (OK, OK, even hibernate/JPA) and add an EJB layer somewhere (together with marvellous DAO, DTO and other magic stuff) ? Just to write more code ? But, surely, it must be my fault. Guido
  17. It sounds like your advocating a non-EJB technology. [rant]How dare you!!!![/rant]

    You can build Spring applications that will happily work with either JPA or JDO. Spring will even let you easily mix and match without much trouble, if that's what your architecture calls for.
    Regarding Spring usage: I'm not that keen on trying to wrap a dependency (to JEE) with another dependency (to Spring). Even if it involves tons of lovely Spring configuration XML ;) So just say no to Spring and get a lightweight/annotation based DI framework just like Google Guice.

    Well, I am still waiting to understand the benefits of the EJB technology.
    Why should I giveup servlet/JSP+template+JDO (OK, OK, even hibernate/JPA) and add an EJB layer somewhere (together with marvellous DAO, DTO and other magic stuff) ?
    Just to write more code
    Why not JSP & template-Servlet-JDO architechture? For starters because JSPs suck big time... They are the biggest reason why vanilla JSF sucks too. JSPs were a bad copy of ASPs anyhow, no better than PHP (which in turn might at least work for small web apps and doesn't require transforming to megabyte sized Servlets, yuck!). With plain Servlets you end up writing the same code over and over again or have a long "Servlet extends ... implements ... extends" -chain for every Servlet to add more advanced features available "out-of-the-box" in just about every Web Framework available nowadays (f.ex JSF). As for EJB 3.0 you don't need DAO/DTOs anymore (as current EntityBeans are serializable, they are normal POJO + annotation). But with EJB 3.0 you get consistent and almost transparent (is there such a thing) scalability. Plus there's nothing wrong with POJO SessionBeans and MDBs. Just my 2c. -ioaalto
  18. It sounds like your advocating a non-EJB technology. [rant]How dare you!!!![/rant]

    You can build Spring applications that will happily work with either JPA or JDO. Spring will even let you easily mix and match without much trouble, if that's what your architecture calls for.


    Regarding Spring usage:
    I'm not that keen on trying to wrap a dependency (to JEE) with another dependency (to Spring). Even if it involves tons of lovely Spring configuration XML ;) So just say no to Spring and get a lightweight/annotation based DI framework just like Google Guice.



    Well, I am still waiting to understand the benefits of the EJB technology.
    Why should I giveup servlet/JSP+template+JDO (OK, OK, even hibernate/JPA) and add an EJB layer somewhere (together with marvellous DAO, DTO and other magic stuff) ?
    Just to write more code

    Why not JSP & template-Servlet-JDO architechture? For starters because JSPs suck big time... They are the biggest reason why vanilla JSF sucks too. JSPs were a bad copy of ASPs anyhow, no better than PHP (which in turn might at least work for small web apps and doesn't require transforming to megabyte sized Servlets, yuck!).

    With plain Servlets you end up writing the same code over and over again or have a long "Servlet extends ... implements ... extends" -chain for every Servlet to add more advanced features available "out-of-the-box" in just about every Web Framework available nowadays (f.ex JSF).

    I meant servlet container+domain objects, without specific reference to JSP/servlet as a controller/rendering technology (in whichever order you like it - or dislike -).
    As for EJB 3.0 you don't need DAO/DTOs anymore (as current EntityBeans are serializable, they are normal POJO + annotation).
    Yes, I know. I know it since I began to use JDO with FastObjects, LiDO, and Kodo 2.x. Even before, I never used a DAO pattern (in classical sense: 1 domain class == 1 DAO class) nor DTO: I had my domain objects.
    But with EJB 3.0 you get consistent and almost transparent (is there such a thing) scalability. Plus there's nothing wrong with POJO SessionBeans and MDBs.

    Just my 2c.

    -ioaalto
    No comment. Guido
  19. Regarding Spring usage:
    I'm not that keen on trying to wrap a dependency (to JEE) with another dependency (to Spring). Even if it involves tons of lovely Spring configuration XML ;) So just say no to Spring and get a lightweight/annotation based DI framework just like Google Guice.
    So are you OK with wrapping or are you not OK with wrapping? I don't get it. Are you saying that wrapping is OK as long as the IoC engine uses annotations? I like Guice a lot. It's just not as mature as Spring. Guice would be a GREAT choice for an architecture. EJB 3.0 would be a GREAT choice for an architecture. My original point was not architectural comparisons, but rather market observations. Spring/Hibernate demand is going up. EJB in general going down. Guice, EJB 3.0 have not penatrated the market yet.


    Well, I am still waiting to understand the benefits of the EJB technology.
    Why should I giveup servlet/JSP+template+JDO (OK, OK, even hibernate/JPA) and add an EJB layer somewhere (together with marvellous DAO, DTO and other magic stuff) ?
    Just to write more code
    Why not JSP & template-Servlet-JDO architechture? For starters because JSPs suck big time... [snip].

    As for EJB 3.0 you don't need DAO/DTOs anymore [snip] But with EJB 3.0 you get consistent and almost transparent (is there such a thing) scalability. Plus there's nothing wrong with POJO SessionBeans and MDBs. So does that mean that JSPs + JDO would be a bad architectural choice? The market comparison of JSP and JSF shows that JSP demand has been consistently high for the last two years, even as JSF demand has increased... You can draw your own conclusions from there. EJB 3.0 => Good doesn't translate to !(EJB 3.0) => Bad MyOpinion("JSP Sucks") != "JSP Sucks"
  20. Solomon, I understand that u have your theory of Spring being more relevant than EJB, and that you have chosen the Eric Stahl path of proving it out by the venerable job boards posting approach, but lets agree on a few things: 1. Spring 2.1 and EJB3 are both new so please compare new apples to new apples... 2. EJB3 is more established in the market than Spring 2.1, do I have to ask the vendors to put up their download numbers to prove it out? 3. Spring is a framework for development that has little comparable technological deployment characteristics as EJB... 4. EJB maintenance is ions more lucrative than Spring maintenance... 5. A few vendor trials does not make a market, BEA and Oracle included, though I have seen something from Glassfish on Spring and JAX-WS as well...there is no customer delineation from jobs boards other than to say, 'let's bring some Spring knowledge for testing of development practices'...the customer adoption of app servers says more, and where r customers placing their bets?: in JEE v. Spring...that seems like a walk-over in JEE's favor... I think u have done a fine job of holding on to your initial theoretical approach, but making claims that EJB3 has not penetrated the market is a shortcoming of your argument, and rather points to a deficiency in your entire theory, as vendors ramp out JEE5 w/ EJB3 support... IMO, your cause of argument for Spring is more convincing in the JEE6 timeframe when the specs can collide, in a manner that allows broader vendor adoption...but right now, there is nothing that suggests a irreversible tide for Spring over EJB from customers, whether or not u believe that or not... douglas dooley douglasdooley.blogspot.com
  21. I understand that u have your theory of Spring being more relevant than EJB
    I wouldn't say that it's a theory.... it's more of a flamebait. The TSS editor faned the flames far more than I originally intended, but that's OK. We had an interesting conversation.
    1. Spring 2.1 and EJB3 are both new so please compare new apples to new apples...
    My original flamebait thesis used "EJB" not EJB3.
    2. EJB3 is more established in the market than Spring 2.1, do I have to ask the vendors to put up their download numbers to prove it out?
    Please, that statistic would be quite interesting... although you can't prove that downloads == jobs. We'd have to get the download statistics for spring as well. In addition, I believe that EJB 3.0 has been around since before Spring became a 1.0 product. As you say, you have to compare apples to apples.
    3. Spring is a framework for development that has little comparable technological deployment characteristics as EJB...
    And therefore what? Knowing how to deploy an EJB will get you a better deployment job? Will it prove that the EJB deployment model is far superior to the Spring development model? Will the existance of an EJB deployment model inherently prove that EJB development is superior in all ways?
    4. EJB maintenance is ions more lucrative than Spring maintenance...
    Can you quantify that? Searches on indeed.com's salary tool shows that EJB and Spring are neck and neck... I would venture to say that there is a higher percentage of EJB maintenance jobs than Spring maintenance jobs... what would that say about the future EJB?
    5. A few vendor trials does not make a market, BEA and Oracle included, though I have seen something from Glassfish on Spring and JAX-WS as well...there is no customer delineation from jobs boards other than to say, 'let's bring some Spring knowledge for testing of development practices'...
    I don't get this point... I view job statistics as 'we need to do something, and need people to do it'
    the customer adoption of app servers says more, and where r customers placing their bets?: in JEE v. Spring...that seems like a walk-over in JEE's favor...
    You're right. No one in their right mind would go out and buy Spring as an Application Server. So what's your point? My original point was about development skills.
    I think u have done a fine job of holding on to your initial theoretical approach
    Thank you
    but making claims that EJB3 has not penetrated the market is a shortcoming of your argument, and rather points to a deficiency in your entire theory, as vendors ramp out JEE5 w/ EJB3 support...
    Fair enough. Vendors are still ramping up their JEE5/EJB3 offerings after 3 years. Riddle me this, batman: When will the EJB3 development jobs start pouring in?
    IMO, your cause of argument for Spring is more convincing in the JEE6 timeframe when the specs can collide, in a manner that allows broader vendor adoption...but right now, there is nothing that suggests a irreversible tide for Spring over EJB from customers, whether or not u believe that or not...

    douglas dooley
    douglasdooley.blogspot.com
    I don't think that there is an irreversible tide. There's a lot of good stuff coming down the line. Specs will be changed, Servers will be sold and frameworks will adapt. My general question I was trying to get an aswer to was: "What technology should a novice enterprise developer focus on learning right now?"
  22. It's incorrect to say that EJB 3 has not penetrated the market. A lot of ours (Oracle) customers are using EJB 3 and JPA in their applications and I get a lot of customer questions. I think book sells are some major of popularity of a technology and Manning is almost out of print of first print of my book EJB 3 In Action within two months of publication and they are going for a reprint. This being 4/5 other EJB 3/JPA books in the market for a year or so. regards Debu Panda http://debupanda.com Author EJB 3 In Action
  23. Great!!! You're the third EJB 3.0 book author on this thread. (The other two being Mike Keith and that JBoss guy)
    It's incorrect to say that EJB 3 has not penetrated the market. A lot of ours (Oracle) customers are using EJB 3 and JPA in their applications and I get a lot of customer questions.
    Can you give some numbers? I'm really interested. The interest for EJB 3.0 can't be denied. Its future can't be denied. What is the present state of EJB 3.0? How many JEE5 application server downloads did you have? How many currently developed projects are thare that use EJB3? What's the percentage of Oracle EJB 3 customers vs. JEE but not EJB 3 customers? How many of Oracle JEE5 users also use Spring?
    I think book sells are some major of popularity of a technology and Manning is almost out of print of first print of my book EJB 3 In Action within two months of publication and they are going for a reprint.
    Sweet. Congratulations.
    This being 4/5 other EJB 3/JPA books in the market for a year or so.


    regards
    Debu Panda
    http://debupanda.com
    Author EJB 3 In Action
    OK... I'll ask it again: Where are the EJB3.0 jobs?
  24. [QUOTE]What's the percentage of Oracle EJB 3 customers vs. JEE but not EJB 3 customers?[/QUOTE] Good question. Like what's the percentage of F-16s deployed around the world compared to the Euro-Fighter? Excellent question indeed. You might want to ask yourself how long Spring has been around compared to EJB3. You might want to ask yourself what the growth rate of Spring was in the first year it was released. Compare than with the first year of EJB3. Then you might find yourself with a meaningful number. AFAIK, ALL the people I know that do J2EE design/development have downloaded JBoss 4.05 with the intention of trialling EJB3. ALL of these people working at some fairly large organisations at fairly influential positions are AT THIS MOMENT trialling EJB3 and are very VERY happy with it so far. The future IS EJB3. Simply because of the flexibility of JPA - you can simply switch your Persistence Provider when a better one arrives.
  25. You might want to ask yourself how long Spring has been around compared to EJB3.
    That seems like a quantifiable question... Doesn't it? I'm pretty sure that Spring was around in 2003. Wasn't EJB 3 around then as well in some form? Part of the problem is defining what EJB 3 meanss... There's EJB 3 the spec; GlassFish, the EJB 3 reference implementation; Oracle's EJB 3 server; JBoss App Server; WebSphear; Fiorinio; other EJB servers too numerous to mention. I don't think that this is a personal question. Let's get down to numbers.
    You might want to ask yourself what the growth rate of Spring was in the first year it was released. Compare than with the first year of EJB3. Then you might find yourself with a meaningful number.
    I'd be glad to find out what the answers to this question is. However IMHO, that's not a meaningful for every single question. My original question was: "which technology should a developer learn now?"
    AFAIK, ALL the people I know that do J2EE design/development have downloaded JBoss 4.05 with the intention of trialling EJB3. ALL of these people working at some fairly large organisations at fairly influential positions are AT THIS MOMENT trialling EJB3 and are very VERY happy with it so far.
    Fair enough... but what logical conclusion can you draw from there that can be quantified?
    The future IS EJB3. Simply because of the flexibility of JPA - you can simply switch your Persistence Provider when a better one arrives.
    :) JPA's definitely the future. JPA is part of the EJB3 spec. JPA is supported by Hibernate and some JDO implementations. Those implementations are strategically supported by Spring as well. There will be plenty of EJB3 servers. Will that translate to EJB3 development efforts? Does that mean that there will be plenty of EJB3 development jobs? Will JPA beans be routed through Spring in EJB3 servers? Seam/JSR 299/Web Beans are compelling alternatives. However, which technology is more compelling now? When will "EJB3" be common enough to need a job force? The term EJB3 has been used rather liberally to cover a whole bunch of distinct topics. What is a fair comparison with Spring and Hibernate, specifically as it relates to a job market?


  26. However IMHO, that's not a meaningful for every single question. My original question was: "which technology should a developer learn now?"
    I think, talking about persistence only, developers should learn ORM. I come from an extensive JDO experience and last year I had to use hibernate for a project. It took me a handful of days (maybe less) to become productive. Ah, btw, having a strong ORM background, it took almost the same amount of time to become productive with JDO too. Well, unless the important thing is being "acronym-compliant" (stolen from another TSS thread, but I really love it). Guido.
  27. I think, talking about persistence only, developers should learn ORM.
    I come from an extensive JDO experience and last year I had to use hibernate for a project.
    It took me a handful of days (maybe less) to become productive.
    Ah, btw, having a strong ORM background, it took almost the same amount of time to become productive with JDO too.
    Well, unless the important thing is being "acronym-compliant" (stolen from another TSS thread, but I really love it).

    Guido.
    Sure, it takes the same amount of time to learn both. The same can probably be said of JPA or even IBatis. An experienced developer can pick up the basics of any ORM quickly. A novice is likely to have a more difficult time with any ORM implementation. In that case, which should one learn first JPA, JDO or Hibernate? The job market says Hibernate.
  28. I think, talking about persistence only, developers should learn ORM.
    I come from an extensive JDO experience and last year I had to use hibernate for a project.
    It took me a handful of days (maybe less) to become productive.
    Ah, btw, having a strong ORM background, it took almost the same amount of time to become productive with JDO too.
    Well, unless the important thing is being "acronym-compliant" (stolen from another TSS thread, but I really love it).

    Guido.


    Sure, it takes the same amount of time to learn both. The same can probably be said of JPA or even IBatis.

    An experienced developer can pick up the basics of any ORM quickly. A novice is likely to have a more difficult time with any ORM implementation.

    In that case, which should one learn first JPA, JDO or Hibernate? The job market says Hibernate.
    Actually I would go the other way round, first learn jpa, it is really hibernate and other orm mappers down to the core and then leverage your knowledge to a more sophisticated (complicated) solution. The reason for this is, that the basic mechanisms do not change, but you get added value and added complexity while in many cases (most orm mappers already have JPA or JPA like APIs on top of their core apis) you still even can keep the API knowledge you already gained.
  29. Actually I would go the other way round, first learn jpa, it is really hibernate and other orm mappers down to the core and then leverage your knowledge to a more sophisticated (complicated) solution. The reason for this is, that the basic mechanisms do not change, but you get added value and added complexity while in many cases (most orm mappers already have JPA or JPA like APIs on top of their core apis) you still even can keep the API knowledge you already gained.
    Guido's point was JDO-centric, so my response was geared as such. Your ideas are sound. The barrier to entry with Hibernate/JPA is low. Learn to implement JPA with a Hibernate flavor. 1) learn ORM concepts 2) understand the concepts via the simpler APIs JPA provides 3) then learn the other Hibernate/JDO implementation details. In fact, we are taking the approach you suggested with my "101" book :).
  30. I think, talking about persistence only, developers should learn ORM.
    I come from an extensive JDO experience and last year I had to use hibernate for a project.
    It took me a handful of days (maybe less) to become productive.
    Ah, btw, having a strong ORM background, it took almost the same amount of time to become productive with JDO too.
    Well, unless the important thing is being "acronym-compliant" (stolen from another TSS thread, but I really love it).

    Guido.


    Sure, it takes the same amount of time to learn both. The same can probably be said of JPA or even IBatis.

    An experienced developer can pick up the basics of any ORM quickly. A novice is likely to have a more difficult time with any ORM implementation.

    In that case, which should one learn first JPA, JDO or Hibernate? The job market says Hibernate.
    Yes, I know. I would like a job market saying ORM, but maybe we like different markets. And different market lords. Guido.
  31. Yes, I know.
    I would like a job market saying ORM,
    I'm not sure what you mean by this. Can you please exmplain?
    but maybe we like different markets.
    And different market lords.

    Guido.
    Are you saying something like: "I like JDO and I'm finding JDO jobs" I point to the job market because it is a simple, straight comparative indicator of current jobs, and can likely be used to indicate the job market within the next couple of years. It's concrete. Which market and market lords do you like? Is there anything concrete or even theoretical you can suggest beyond "we like different markets?"
  32. Yes, I know.
    I would like a job market saying ORM,


    I'm not sure what you mean by this. Can you please exmplain?
    Sure, I would prefer a job market requesting, primarly, technologies knowledge rather than specific products.


    but maybe we like different markets.
    And different market lords.

    Guido.


    Are you saying something like: "I like JDO and I'm finding JDO jobs"
    Yes, I like JDO and it is rather obvious from my other posts too, but it is irrelevant.


    I point to the job market because it is a simple, straight comparative indicator of current jobs, and can likely be used to indicate the job market within the next couple of years. It's concrete.

    Which market and market lords do you like? Is there anything concrete or even theoretical you can suggest beyond "we like different markets?"
    I would like market lords not being acronym-driven (it doesn't matter if the acronym corresponds to a very good product). Just to clarify further I would be more impressed by a developer claiming to be an ORM expert rather than a hibernate expert. Guido.
  33. Just to clarify further I would be more impressed by a developer claiming to be an ORM expert rather than a hibernate expert.

    Guido.
    Fair enough... but that doesn't answer my question. Which existing market over-lord do you server? Yourself?
  34. Just to clarify further I would be more impressed by a developer claiming to be an ORM expert rather than a hibernate expert.

    Guido.


    Fair enough... but that doesn't answer my question. Which existing market over-lord do you server? Yourself?
    I don't know if I am catching your point (maybe my english understanding is insufficient here). No, I am not serving myself. I live in a company that, fortunately, lets me promote things differently. But, OK, yes I can see that our (IT) customers (job market lords ?) "know" spring, hibernate, JPA. Anyway, I don't like this overstated "acronym-based" recruiting policy. I do not resign to eat this soup. Guido.
  35. No, I am not serving myself. I live in a company that, fortunately, lets me promote things differently.
    You have kind overlords, indeed.
    But, OK, yes I can see that our (IT) customers (job market lords ?) "know" spring, hibernate, JPA.
    Anyway, I don't like this overstated "acronym-based" recruiting policy.
    I do not resign to eat this soup.

    Guido.
    fair enough. However, the job-market overlords like to eat "acronym-based" alphabet soup. I don't think it's a good thing, but it's something that exists in a very broad way. Do you know about the "Golden Rule?" "He who has the gold makes the rules." The buyers of the technology services can make the rules about how they hire developers.
  36. Numbers and momentum[ Go to top ]

    I can give you a few from two perspectives: downloads on sf.net for JBoss and Hibernate projects related to EJB3 and JPA: * Downloads of a standalone distribution of the JBoss EJB3 project since 10/2004: 183199 * JEMS installer which bundles EJB 3.0 (not same as JBoss Appserver download): 201923 * JBoss 4.2 which bundles EJB 3.0: ~65000 * JBoss 5 betas which bundles EJB 3.0: ~80000 * Hibernate's JPA implementation: 135269 * Hibernate Annotations (which is JPA based): 202561 So, total downloads solely related to JPA: ~337K Total downloads solely related to EJB3: ~550K Total EJB3 + JPA related downlaods: ~ 887K Compare that to Spring 2.x downloads: ~600K Spring 1.x downloads: 946K Hibernate 3.x downloads: 1445K Hibernate 2.x downloads: 495K Now that's just JBoss. You also have Glassfish, Open JPA, Oracle, and now Geronimo communities not included in these numbers. Also, my EJB 3.0 book has been out a year and has sold ~12K copies +/- a thousand (haven't gotten check yet from last quarter). So, all and all I think there is pretty compelling evidence that EJB3 and JPA has momentum. Bill
  37. Re: Numbers and momentum[ Go to top ]

    I can give you a few from two perspectives:

    downloads on sf.net for JBoss and Hibernate projects related to EJB3 and JPA:
    I'm not sure if download statistics count as two perspectives, but I'll definitely grant you that the numbers are compelling.
    * Downloads of a standalone distribution of the JBoss EJB3 project since 10/2004: 183199

    * JEMS installer which bundles EJB 3.0 (not same as JBoss Appserver download): 201923

    * JBoss 4.2 which bundles EJB 3.0: ~65000

    * JBoss 5 betas which bundles EJB 3.0: ~80000
    wow. more downloads for JBoss 5 beta than JBoss 4.2. I guess that makes sense.
    * Hibernate's JPA implementation: 135269
    * Hibernate Annotations (which is JPA based): 202561
    This is interesting... The question is how to interpret this specific statistic. Sure, JPA is part of the EJB spec, but it seems to have taken on a life of its own. All of the stand alone ORMs basically implement JPA. I'm not going to interpret this fact here, I'm just pointing it out.
    So, total downloads solely related to JPA: ~337K
    Total downloads solely related to EJB3: ~550K
    Total EJB3 + JPA related downlaods: ~ 887K
    The interesting statistic to me is the "only JPA" vs "purely EJ3." I read that as more as "standalone hibernate with JPA" vs "EJB3."
    Compare that to Spring 2.x downloads: ~600K
    Spring 1.x downloads: 946K
    Hibernate 3.x downloads: 1445K
    Hibernate 2.x downloads: 495K
    How do you interpret these statistics?
    Now that's just JBoss.
    And what a fine job ya'all are doing.
    You also have Glassfish, Open JPA, Oracle, and now Geronimo communities not included in these numbers.
    You probably count WebLogic and WebSphere (eventually). As EJB3 compliant servers.
    Also, my EJB 3.0 book has been out a year and has sold ~12K copies +/- a thousand
    Impressive indeed. Congratulations. You deserve it
    (haven't gotten check yet from last quarter).
    Did you really write the book for the money?
    So, all and all I think there is pretty compelling evidence that EJB3 and JPA has momentum.

    Bill
    Yes, EJB3 has momentum. JPA has momentum. I never argued that it doesn't. I ask this question to you as a vendor. What do you use download statistics for? I understand that they definitely mean that the world at large cares about your product, and therefore your outlook looks good. How does that translate to the outlook of an application developer? My take is that the job market stats are probably a "backward looking" statistic and aren't perfect about where the jobs will be a year from now. The download statistics are probably "forward indicators" as far as the job markets are concerned. Bottom line on my take. 1) There is a clear distinction between the perception of "EJB3" and JPA. JPA ~ (EJB3 | Hibernate | JDO | Toplink) 2) The simplistic job market alphabet soup statistics and the raw download statistics can be interpreted in different ways depending on perspective. I'm really interested on the communities take on both sets of statistics. 3) Spring will NOT overtake EJB3 as a whole. However, I would venture to say that right now there is probably a more favorable demand:supply ratio for Hibernate than for EJB3... The same would likely hold for Spring. Again, that's a purely subjective interpretation of the statistics 4) I'm not sure where the EJB3 momentum is going from a job perspective... Where do you think the EJB3 job market is going?
  38. Re: Numbers and momentum[ Go to top ]

    I'm not sure if download statistics count as two perspectives
    Two perspectives were downloads and book sales.
    wow. more downloads for JBoss 5 beta than JBoss 4.2. I guess that makes sense.
    JBoss 4.2 has only been out a month.
    How do you interpret these statistics?
    I interpret them in two ways. 1. EJB3/JPA is more prevalent than the Spring community would lead you to believe. 2. That Spring is not as prevalent as the Spring community would lead you to believe. (That's not saying it isn't prevalent, but claims like "Spring is the defacto Java EE" are just silly).
    Did you really write the book for the money?
    I wasn't going to write it for free. There's a JBoss workbook at the end. Great way to promote our stuff.
    I ask this question to you as a vendor. What do you use download statistics for?
    I use the same statistics as the vendor Interface21 does: www.sourceforge.net. Bill
  39. Re: Numbers and momentum[ Go to top ]

    I'm not sure if download statistics count as two perspectives


    Two perspectives were downloads and book sales.
    Ah... I missed that point. Is there a good place to get an overview of book sales statistics?
    I interpret them in two ways.
    1. EJB3/JPA is more prevalent than the Spring community would lead you to believe.
    IMHO, EJB3 and JPA should be considered as separate topics of conversation... but that's a separate discussion :). My question still stands: When do you think that there will be EJB3 jobs? There are a couple hundred EJB3 jobs on indeed, EJB 3.0 pays more than Hibernate or Spring and EJB3 jobs are growing fast. It shows that there is momentum, as you say, and with download statistics show that there is going to be an EJB3 explosion soon... With that said, what is the expected time-line that EJB3 will be dominant? 2. That Spring is not as prevalent as the Spring community would lead you to believe. (That's not saying it isn't prevalent, but claims like "Spring is the defacto Java EE" are just silly). :) Fair enough. That specific claim is silly and self promoting... However, the momentum and current positioning of enterprise technologies that don't rely directly on a server (for example Hibernate and Spring) are gaining traction at incredible rates, to the point where it looks like there are about 1 Hibernate (and/or Spring) job for every 2 EJB jobs (and yes, Hibernate is still beating Spring in the job market).
    I ask this question to you as a vendor. What do you use download statistics for?


    I use the same statistics as the vendor Interface21 does: www.sourceforge.net.

    Bill
    The question wasn't about how you get the statistics.... Although I did learn about more statistics gathering mechanisms. The question is: what do those statistics tell vendors? I care about how to get a job (and with it $$$). You, as a software vendor, probably care about how well your products is doing and therefore how it will change your bottom line (via consulting/training/support). Do those statistics show you anything else?
  40. Re: Numbers and momentum[ Go to top ]

    Ah... I missed that point. Is there a good place to get an overview of book sales statistics?
    I get units sold when I get my check from O'Reilly. Given that the 12K number I gave you was still a guestimation cuz I don't understand O'Reilly's reporting :)
    With that said, what is the expected time-line that EJB3 will be dominant?
    I don't know if or when... Who knows, maybe we'll all be doing SCA in a few years ;-p Bil
  41. tracking opportunities[ Go to top ]

    This should be done by the vendors to substantiate their platforms as being enterprise-ready and demonstrating up-take of new standards...I credit Bill with providing some useful data that goes a long way in showing why JBoss is a leader in the app development and deployment market... As this is a competitive market, i don't see why a competitive feature of most vendors would b to b more explicit about what their download, project-based, and deployment numbers r, such as how many r in deployment of EJB3 apps, without mentioning the customer identities... Raw job board postings are trailers, and this is reflected in the ~6 month timelag for new technology adoption, which is why Spring is enjoying some success from development departments, as well as ISV penetration (intriguing read on GigaSpaces), but in my mind without more apps out there that r certified Spring, there is no way to understand the opportunity available for potential Spring developers... The question of app framweworks is a useful discussion, as it is generally considered a standard by the time a groundswell of developers have promoted it, but as with ADF, Spring and Hibernate are non-standard implementations with standard technologies...when its non-portable, its not standard, its that simple, IMO... Somewhere along the line, there has been a decreased emphasis on portability, as the J2EE/JEE app server vendors have chosen to do 'extensions', and r now paying 4 it by seeing the increased emphasis on Spring capabilities over portability...I am sure I am going to be considered naive 4 putting such an emphasis on this requirement of the JEE architecture, but it is the only way ISVs can compete with Microsoft, and that still remains on my radar as something to value... Spring solves the problem of EJB2, whether that is enough to overcome the value-benefits of EJB3 remains to be seen, but there is much more to consider than the current employment postings, and that should be made explicit by Sun, Red Hat, and whoever else cares about portability...in the end, Hibernate succeeded in filling a vacuum of need, whether Spring does depends as much on the ability of customers to create a case for deployment of EJB3 portability v. Spring efficiency... i welcome responses to this purported flame...
  42. Re: tracking opportunities[ Go to top ]

    As this is a competitive market, i don't see why a competitive feature of most vendors would b to b more explicit about what their download, project-based, and deployment numbers r, such as how many r in deployment of EJB3 apps, without mentioning the customer identities...
    Yes, it would be nice if there was some way to see how many GlassFish, JBoss, Geronimo and "community edition" downloads there are. However, how would you compare "value" in a download of free software in comparison with sale of proprietary software?
    Raw job board postings are trailers, and this is reflected in the ~6 month timelag for new technology adoption,
    That's a very interesting hypothesis... I'm sure that there is a way to get download statistics from 6 months ago and compare them to downloads and jobs today to get some kind of meaningful information.
    which is why Spring is enjoying some success from development departments, as well as ISV penetration (intriguing read on GigaSpaces),
    Um... Spring has been around for about 4 years. but in my mind without more apps out there that r certified Spring, there is no way to understand the opportunity available for potential Spring developers... I respectfully disagree there. Current job stats can do just that.
    The question of app framweworks is a useful discussion, as it is generally considered a standard by the time a groundswell of developers have promoted it, but as with ADF, Spring and Hibernate are non-standard implementations with standard technologies... when its non-portable, its not standard, its that simple, IMO...
    I don't exactly understand this point. I don't know much about ADF, but Spring and Hibernate are both ultra-portable... They can run in any JEE server. They can run in JSE environments such as unit test environments. They can run in Rich App environments. I'm not sure about JME environments, but I wouldn't be too surprised to hear that Spring and/or Hibernate work there as well.
    Somewhere along the line, there has been a decreased emphasis on portability, as the J2EE/JEE app server vendors have chosen to do 'extensions', and r now paying 4 it by seeing the increased emphasis on Spring capabilities over portability...
    Please explain what you mean by this, at least how it relates to Spring. JEE servers can run Spring apps without any custom extensions what-so-ever. If JBoss app servers make run Hibernate easier, does that lessen the portability of Hibernate?
    I am sure I am going to be considered naive 4 putting such an emphasis on this requirement of the JEE architecture, but it is the only way ISVs can compete with Microsoft, and that still remains on my radar as something to value...
    Hibernate, Spring and GigaSpaces all use the parts of JEE that make sense to their products. They all value JEE, or at least significant parts of it.
    Spring solves the problem of EJB2, whether that is enough to overcome the value-benefits of EJB3 remains to be seen,
    EJB3 still has a lot to prove. Spring has proven itself. Many lessons from EJB3/JEE and other technologies will be quickly added into Spring.
    but there is much more to consider than the current employment postings, and that should be made explicit by Sun, Red Hat, and whoever else cares about portability...in the end, Hibernate succeeded in filling a vacuum of need, whether Spring does depends as much on the ability of customers to create a case for deployment of EJB3 portability v. Spring efficiency...

    i welcome responses to this purported flame...
    Again, Spring is portable. Spring is efficient. Spring does have momentum. Spring does have plenty of support from ISVs. There are plenty of Spring Jobs. Spring books are selling really well. Granted, there is plenty of momentum with JEE 5 and EJB3 momentum, but I would say (again), that the onus is on EJB3 to prove itself.
  43. Dear Solomon[ Go to top ]

    I admit to being under-educated on the execution of Spring in an app server environment, but r u telling me that the apps that r derived from spring are portable across app servers, i could care less about whether spring itself can deploy to an app server, what i care about is whether the apps can be portable...when it is not part of the spec, it will require spring, another layer, to be present, and there is no guarantee that this will be implemented the same way by all app server vendors... EJB3 is a mainstay of the JEE5 environment, r u saying that even after all i said about getting download #'s, and comparing implementation results, that u would still be under-impressed by EJB3's penetration in the market: that is blind spring support at the expense of looking at alternative and competing technologies... spring is a potential factor to customer deployments once it becomes part of the spec., or some spec., or gets rid of its EJB bias, or its proponents stop the either-or discussions like EJB has had its day, and that EJB3 needs to "prove" itself...there is nothing that says in a job board posting that spring is the preferred development methodology of that firm, let alone ready to utilize for deployable apps in the enterprise... have we not had this discussion ad nauseum?
  44. Re: Dear Solomon[ Go to top ]

    I admit to being under-educated on the execution of Spring in an app server environment, but r u telling me that the apps that r derived from spring are portable across app servers, i could care less about whether spring itself can deploy to an app server, what i care about is whether the apps can be portable...when it is not part of the spec, it will require spring, another layer, to be present, and there is no guarantee that this will be implemented the same way by all app server vendors...
    Sorry for not understanding your position. So basically, are you telling me something that doesn't implement the JEE standard and isn't downloadable with all JEE Servers is inherently bad for JEE? I agree that Spring is usually packaged as part of the application, but I'm not sure that the implications are anywhere near as grave to what you're suggesting. I would guess a huge majority of non-trivial applications/servers require lots of third party jars. You saw that Rails vs. Java video right? Has EJB3 really done that much to improve the prospects of requiring third party add-ons? Applications that are designed take advantage of Spring can take advantage of every single feature of a JEE server, including JPA and stateless session beans. One of the comments on this thread was about clustering not being part of the spec...
    EJB3 is a mainstay of the JEE5 environment, r u saying that even after all i said about getting download #'s, and comparing implementation results, that u would still be under-impressed by EJB3's penetration in the market
    I'm not convinced that EJB is the core of the JEE5 environment. Download numbers cannot inherently prove any such claim. Comparing implementation results is subjective. The real-life results from early adopters will be my yard stick. The comparison of download statistics can't easily be used to prove the usage statistics of programming models. There is no way to directly get from one to the other. The download statistics are a very compelling story, but I can't agree that the story that your telling is the one that's being told by the evidence.
    : that is blind spring support at the expense of looking at alternative and competing technologies...
    Is spec support at the expense of looking at alternative and competing technologies "blinding"? The Spring and Hibernate "story" is compelling to developer who want a job in the next couple of years. The Spring and Hibernate story is compelling to conservative development institutions who care about service and a talent pool. I would say that those two populations have a much stronger reason to use Spring. There are plenty of shops that will evaluate EJB3. Heck, I'm a bit jealous of them; I'm stuck at a Web's Fear shop, stuck on a version that supports Java 1.4, no less. Can you tell me that EJB3 made it yet? Can you tell me that EJB3 will dominate other DEVELOPMENT MODELS in 6 months or a year from now? That's what I mean by EJB3 has something to prove.
    spring is a potential factor to customer deployments once it becomes part of the spec., or some spec.,
    What you're saying is just unsubstantiated and biased. Prior results and peer usage are much more important that just "being in the spec". It's almost as unsubstantiated as Spring folks claiming to be the "de-facto standard."
    or gets rid of its EJB bias
    When EJB proves itself in the market, Spring will add what its customers want. Spring does integrate with stateless session beans and JPA now.
    or its proponents stop the either-or discussions like EJB has had its day, and that EJB3 needs to "prove" itself...
    I'm not going to comment on this :o)
    there is nothing that says in a job board posting that spring is the preferred development methodology of that firm, let alone ready to utilize for deployable apps in the enterprise...
    Didn't you say that job statistics are backward looking? I interpreted that as job statistics showing a correlation to methodology preference and product trust. I care about where the development jobs will be, because that's what I do for a living. I haven't heard any compelling evidence to say that EJB3 will be dominant anytime soon. However, I definitely agree that EJB3 is gaining momentum and is a great choice for a platform... IMHO, the future dominant development methodology is still strongly in question. With all of that said, there's even less that says the EJB3 is the "preferred development methodology of [a] firm, let alone ready to utilize for deployable apps in the enterprise." I say that for EJB3, not the JEE server at large. Download statistics and book buy statistics simply don't prove an EJB3 preference over alternatives.
    have we not had this discussion ad nauseum?
    Yes, but I can keep on going, if you're up for it. Maybe we should take a 6 month break, and see from there.... Wasn't that the time-frame you suggested was appropriate for job statistics? Hopefully by then I'll be able to give you better book purchase statistics from my own book :o)
  45. portability and downloads[ Go to top ]

    Solomon, I am not saying that add-on development tools beyond the JEE spec. are inherently bad for developers, but I do think that a restriction on what is portable means that it is a proprietary architecture...like I have said on different threads, it will take BEA and/or Oracle to step up to Spring and make it their preferred development model before adoption means a standard, and then it will merely be a sub-segment of the Enterprise Java platform, at best... You discount EJB3's uptake on the basis that even though JEE5 servers are being downloaded by the thousands every day, that developers are probably not developing practices around EJB3 even after it has been credited with being the most comprehensive, successful, and ease-of-use advancement in the new spec...I guess we can agree to be at an impasse, that you find downloads lacking and i find job postings incomplete... however, your reference that "conservative" development outfits will find a larger talent pool for Spring and Hibernate is silly to me, again you are mixing and matching technologies and opportunities to where it benefits your argument...EJB3 and Spring 2 are the new development models, but EJB as an architecture for deployment has been around for some years and continues to be more widely adopted than Spring... you minimize the impact that a spec. has, and why Sun has gifted the app server industry in the past to WebLogic in order to maintain a marketplace for its J2EE/JEE technology, just because 'a lot' of developers have chosen spring does not make it a de facto standard and does not ensure portability of apps made with it, whether u package Spring with the app or not... more than happy to continue to talk about this, and will wait for your blog post in 6 months about the job situation for EJB3 and Spring 2, when we have a clearer picture on the specific spec.'s and standards, until then, best of luck with the book, with the development of ur skills around Spring, and how that bears out in the marketplace...i am looking for something more than just anecdotal adoption evidence, even as i rely on those download stats to tell me the JCP has done a good job with JEE5...we'll see, lots of developments still to come, douglas dooley
  46. Solomon,

    I am not saying that add-on development tools beyond the JEE spec. are inherently bad for developers, but I do think that a restriction on what is portable means that it is a proprietary architecture...
    So basically I've just misunderstood your semantics. If I understand you correctly, you're saying "proprietary => not portable." I still think that your definition of portable is incomplete. From Wikipedia:
    Portable software, software that can easily be ported to multiple platforms
    porting:
    In computer science, porting is the process of adapting software so that an executable program can be created for a computing environment that is different from the one for which it was originally designed (e.g. different CPU, operating system, or third party library). The term is also used in a general way to refer to the changing of software/hardware to make them usable in different environments.
    like I have said on different threads, it will take BEA and/or Oracle to step up to Spring and make it their preferred development model before adoption means a standard, and then it will merely be a sub-segment of the Enterprise Java platform, at best...
    I'm missing your point here completely. What do client adoption and proposed "standards" (in the way you describe) have to do with each other? There is a relationship, to be sure, but the Spring guys' claim to be the "de-facto" standard isn't hinged on Oracle or BEA adoption alone; rather they claim that title based on perceived user adoption (which we're all having a hard time quantifying) and ISV adoption as a whole. I'm not saying that Spring is the "de-facto" standard. I'm respectfully disagreeing with your assessment about the need for BEA and Oracle to "step up" The next step in your argument is a bit of a mystery to me as well. Why would Spring become "merely be a sub-segment of the Enterprise Java platform?" Isn't it a "mere" sub-segment of a platform already? I'm not sure what you're implying.
    You discount EJB3's uptake on the basis that even though JEE5 servers are being downloaded by the thousands every day,
    I'm merely pointing out that a JEE5 server download is not necessarily an EJB3 uptake. JEE5 is much a much bigger product than EJB3. With all of that said... Would it be fair to say that EJB3's uptake is in the "Early Adopter" phase? that developers are probably not developing practices around EJB3 even after it has been credited with being the most comprehensive, successful, and ease-of-use advancement in the new spec...
    I'm not saying that either. I would appear to me that JPA is one of the most impressive achievements of the EJB3 spec. Any JDO, Hibernate or TopLink usage through JPA is a "practice around EJB3" to some extent. EJB3 spec is impressive, but it still seems to be adopted by a small segment of the overall Enterprise Java community. Perhaps I just have a different definition of "adopted"...
    I guess we can agree to be at an impasse, that you find downloads lacking and i find job postings incomplete...
    I find searching job postings incomplete as well. However, they do have the charming quality of being more precisely targetable than download statistics The imprecision of the download statistics can't inherently prove the uptake of EJB3. They definitely imply EJB, but it also can't prove that the adoption of EJB3 is so widespread to the point that that it is dominant. I'm not interested in either being right or achieving an impasse... I would like to understand some more of the "bigger" picture.
    however, your reference that "conservative" development outfits will find a larger talent pool for Spring and Hibernate is silly to me, again you are mixing and matching technologies and opportunities to where it benefits your argument...
    Perhaps my argument is incomplete... My points are meant to prove specific things... I was under the impression that EJB3 is in the "Eary Adopter" phase and therefore mentioning the "conservatives" to try to prove that point.
    EJB3 and Spring 2 are the new development models,
    :)
    but EJB as an architecture for deployment has been around for some years and continues to be more widely adopted than Spring...
    Sure. But where are we going from here? There are 2 EJB jobs for every Hibernate and Spring job. 2:1 is an incredible ratio for any proprietary software compared to a standard. Spring and Hibernate are both still gaining fast.
    you minimize the impact that a spec. has, and why Sun has gifted the app server industry in the past to WebLogic in order to maintain a marketplace for its J2EE/JEE technology,
    Now that's an interesting note. Are you really saying that Sun just gave away the marketplace to BEA?
    just because 'a lot' of developers have chosen spring does not make it a de facto standard
    Agreed. That Spring guy's "de facto" statement is unproven and tongue-in-cheek.
    and does not ensure portability of apps made with it, whether u package Spring with the app or not...
    We'll agree to disagree on this point
    more than happy to continue to talk about this, and will wait for your blog post in 6 months about the job situation for EJB3 and Spring 2, when we have a clearer picture on the specific spec.'s and standards, until then, best of luck with the book, with the development of ur skills around Spring, and how that bears out in the marketplace...
    Thanks. Good luck in your endeavors.
    i am looking for something more than just anecdotal adoption evidence,
    Is there an industry standard "adoption evidence?" I would think that the job market stats are more than anecdotal.
    even as i rely on those download stats to tell me the JCP has done a good job with JEE5...
    The JCP has done a Good Job. JPA seems to have been picked up really quickly. JBoss has done a terrific job. I'm not arguing that the spec community did anything but a good job. I'm merely arguing that the proofs presented that "EJB3 == Better than alternatives" are incomplete. I don't think that there is a way to easily prove any of "Technology X == Better than alternatives". EJB3 is the standard, but isn't it relatively new? Doesn't that inherently mean that it still has "something to prove?"
    we'll see, lots of developments still to come,

    douglas dooley
    Oh, I don't doubt that at all. I'll be watching the developments. I'll even check out EJB3 :) Solomon Duskis
  47. Re: Dear Solomon[ Go to top ]

    I admit to being under-educated on the execution of Spring in an app server environment, but r u telling me that the apps that r derived from spring are portable across app servers, i could care less about whether spring itself can deploy to an app server, what i care about is whether the apps can be portable...when it is not part of the spec, it will require spring, another layer, to be present, and there is no guarantee that this will be implemented the same way by all app server vendors...
    Portability is just not a problem with Spring, but also it is an advantage, comparing to EJB or EJB3, exactly because it is a finished product, that does not depend on any spec. I don't know if with EJB3 your app is portable through all JavaEE Application Servers, but with EJB2 it definitely was not. With Spring, on the other hand, your app will not only be portable to any JavaEE App Server, but also to any J2EE App Server. And also to any JSP Container. (Unless you tie Spring with EJB, of course.) So, if your biggest concern is portability, you should start using Spring! ;)
  48. Re: tracking opportunities[ Go to top ]

    As this is a competitive market, i don't see why a competitive feature of most vendors would b to b more explicit about what their download, project-based, and deployment numbers r, such as how many r in deployment of EJB3 apps, without mentioning the customer identities...
    Yes, it would be nice if there was some way to see how many GlassFish, JBoss, Geronimo and "community edition" downloads there are. However, how would you compare "value" in a download of free software in comparison with sale of proprietary software?
    Raw job board postings are trailers, and this is reflected in the ~6 month timelag for new technology adoption,
    That's a very interesting hypothesis... I'm sure that there is a way to get download statistics from 6 months ago and compare them to downloads and jobs today to get some kind of meaningful information.
    which is why Spring is enjoying some success from development departments, as well as ISV penetration (intriguing read on GigaSpaces),
    Um... Spring has been around for about 4 years. but in my mind without more apps out there that r certified Spring, there is no way to understand the opportunity available for potential Spring developers... I respectfully disagree there. Current job stats can do just that.
    The question of app framweworks is a useful discussion, as it is generally considered a standard by the time a groundswell of developers have promoted it, but as with ADF, Spring and Hibernate are non-standard implementations with standard technologies... when its non-portable, its not standard, its that simple, IMO...
    I don't exactly understand this point. I don't know much about ADF, but Spring and Hibernate are both ultra-portable... They can run in any JEE server. They can run in JSE environments such as unit test environments. They can run in Rich App environments. I'm not sure about JME environments, but I wouldn't be too surprised to hear that Spring and/or Hibernate work there as well.
    Somewhere along the line, there has been a decreased emphasis on portability, as the J2EE/JEE app server vendors have chosen to do 'extensions', and r now paying 4 it by seeing the increased emphasis on Spring capabilities over portability...
    Please explain what you mean by this, at least how it relates to Spring. JEE servers can run Spring apps without any custom extensions what-so-ever. If JBoss app servers make run Hibernate easier, does that lessen the portability of Hibernate?
    I am sure I am going to be considered naive 4 putting such an emphasis on this requirement of the JEE architecture, but it is the only way ISVs can compete with Microsoft, and that still remains on my radar as something to value...
    Hibernate, Spring and GigaSpaces all use the parts of JEE that make sense to their products. They all value JEE, or at least significant parts of it.
    Spring solves the problem of EJB2, whether that is enough to overcome the value-benefits of EJB3 remains to be seen,
    EJB3 still has a lot to prove. Spring has proven itself. Many lessons from EJB3/JEE and other technologies will be quickly added into Spring.
    but there is much more to consider than the current employment postings, and that should be made explicit by Sun, Red Hat, and whoever else cares about portability...in the end, Hibernate succeeded in filling a vacuum of need, whether Spring does depends as much on the ability of customers to create a case for deployment of EJB3 portability v. Spring efficiency...

    i welcome responses to this purported flame...
    Again, Spring is portable. Spring is efficient. Spring does have momentum. Spring does have plenty of support from ISVs. There are plenty of Spring Jobs. Spring books are selling really well. Granted, there is plenty of momentum with JEE 5 and EJB3 momentum, but I would say (again), that the onus is on EJB3 to prove itself.
  49. Re: Numbers and momentum[ Go to top ]

    Let's stop this war, pull out the troops and decide - Spring, Hibernate/JPA for small to mid scale applications - JEE/EJB3/JPA for large scale complex applications with clustering etc.
  50. Re: Numbers and momentum[ Go to top ]

    Let's stop this war, pull out the troops and decide

    - Spring, Hibernate/JPA for small to mid scale applications
    - JEE/EJB3/JPA for large scale complex applications with clustering etc.
    It's not a war, it's a friendly debate. We've been civil, for the most part ;). (Spring and (Hibernate | TopLink)) and (EJB 3 Servers or some clustered environment) can scale perfectly well, thank you very much. The Serverside just posted a story about GigaSpaces/Spring integration. OSGi Clustered Servers are around the corner. In addition to scaling applications... Which development model scales better? Some will say one way, and other will say the other. That's OK. They're all good choices. They all will compete with each other and good ole' MS. That's not a bad thing. For example, the EJB spec leaders took the "proprietary" ORM community's success very seriously, and ended up with an abstract and meaningful API (JPA) that will benefit everyone. There is credit to go all around. All of the Java choices will have profound similarities and differences. It will be up to us to choose and direct those technologies in meaningful ways...
  51. Re: Numbers and momentum[ Go to top ]

    Let's stop this war, pull out the troops and decide

    - Spring, Hibernate/JPA for small to mid scale applications
    - JEE/EJB3/JPA for large scale complex applications with clustering etc.
    I think you should try EJB3 for a "small to mid scale application". I think you'll be very surprised how fast it is to get something up and running. It is much simpler than Spring.
  52. Re: Numbers and momentum[ Go to top ]

    Let's stop this war, pull out the troops and decide

    - Spring, Hibernate/JPA for small to mid scale applications
    - JEE/EJB3/JPA for large scale complex applications with clustering etc.
    Well, why hibernate is not suited for complex applications is a real mistery. BTW, JPA is a spec and it is possible to produce implementation that won't scale neither kicking in the ass. Another thing, EJB3 is a spec and, for example, in J2EE 1.4 spec the word cluster never appear in the doc. So, how can you state that J2EE (that IS a spec) is for large complex applications with clustering. I still think that there is some approximation using some terms, or a bad habit of clueless repetition of google results in the worst case. Guido P.S. How many sq meters is large a "large scale complex applications" ?
  53. Re: Numbers and momentum[ Go to top ]

    In the second option, when I said JPA, I meant any OR mapping tool underneath, including Hibernate, depending on the JEE server being used. As far as clustering, the reality is that most JEE app server vendors do provide clustering support, irrespective of what the spec says. Moreover, clustering is a deployment issue. What would like the JEE spec to say about clustering? I take my pick on technology, based what's appropriate. Being a zealot or emotionally attached to certain technology does not help. I thought we all love google search :-)
  54. Re: Numbers and momentum[ Go to top ]

    Being a zealot or emotionally attached to certain technology does not help.
    Oh yes, I know very well that any attempt to be a little more rigorous and precise is quite often labelled as being zealot. Guido.
  55. It's incorrect to say that EJB 3 has not penetrated the market. A lot of ours (Oracle) customers are using EJB 3 and JPA in their applications and I get a lot of customer questions.
    I would be very surprised if Oracle customers used something different. They have the RI of JPA !!! And, well, I don't know if "a lot of customer questions" is a good sign. It depends on the questions. Guido.
  56. It's incorrect to say that EJB 3 has not penetrated the market. A lot of ours (Oracle) customers are using EJB 3 and JPA in their applications and I get a lot of customer questions.

    I would be very surprised if Oracle customers used something different. They have the RI of JPA !!!
    And, well, I don't know if "a lot of customer questions" is a good sign. It depends on the questions.

    Guido.
    Actually having used the RI in two projects I can say, that the JPA RI is quite good, ok it was not entprise level stuff, but I definitely didnt have to many problems. One being a bug which was ironed out in the later JPA implementations (I used a very old 1.xx one) and the other one a misunderstanding of the somewhat confusing object traversal in JPQL which in later incarnations of the JPA ri throws an error, the earlier ones didnt. Thats basically it. I was quite happy with the RI, for the small to medium sized projects I used it for (handful maybe a dozend or so users) it was the perfect fit. Easy to install, easy to deploy, clean api, object mapping was a breeze thanks to forward engineering of the objects into the db, good speed, no dependencies and it worked and did what it should do mostly. I had worse experiences with other orm systems. I can see a lot of szenarios where the RI probably does not cut it, but for the szenarios I used it for it was perfect.
  57. It's incorrect to say that EJB 3 has not penetrated the market. A lot of ours (Oracle) customers are using EJB 3 and JPA in their applications and I get a lot of customer questions.

    I would be very surprised if Oracle customers used something different. They have the RI of JPA !!!
    And, well, I don't know if "a lot of customer questions" is a good sign. It depends on the questions.

    Guido.


    Actually having used the RI in two projects I can say, that the JPA RI is quite good, ok it was not entprise level stuff, but I definitely didnt have to many problems.
    One being a bug which was ironed out in the later JPA implementations (I used a very old 1.xx one)
    and the other one a misunderstanding of the somewhat confusing object traversal in JPQL which in later incarnations of the JPA ri throws an error, the earlier ones didnt.

    Thats basically it.
    I was quite happy with the RI, for the small to medium sized projects I used it for (handful maybe a dozend or so users) it was the perfect fit. Easy to install, easy to deploy, clean api, object mapping was a breeze thanks to forward engineering of the objects into the db, good speed, no dependencies and it worked and did what it should do mostly.
    I had worse experiences with other orm systems.

    I can see a lot of szenarios where the RI probably does not cut it, but for the szenarios I used it for it was perfect.
    Obviously the RI is good: it is Toplink. It would be strange for Oracle to promote something different. Guido
  58. Obviously the RI is good: it is Toplink.
    It would be strange for Oracle to promote something different.
    Guido
    No one is arguing that the JPA RI is bad. Werner was just saying that there are some inherent limitations in JPA that make restrict its use large projects. I read that as: 'Small to medium projects can get away with JPA RI. Bigger projects are likely to need more of the Toplink infrastructure than "pure" JPA.' I find that rationale agrees with technical reality. It also makes sense from a marketing strategy.
  59. Obviously the RI is good: it is Toplink.
    It would be strange for Oracle to promote something different.
    Guido


    No one is arguing that the JPA RI is bad. Werner was just saying that there are some inherent limitations in JPA that make restrict its use large projects. I read that as: 'Small to medium projects can get away with JPA RI. Bigger projects are likely to need more of the Toplink infrastructure than "pure" JPA.'

    I find that rationale agrees with technical reality. It also makes sense from a marketing strategy.
    Exactly, maybe I was somewhat unclear, but the JPA ri is really orm stripped down to the core, if you need Criteria API, two level caching, fine grained locking mode controls on transaction level via apis etc... you have to move up higher, but I personally feel, that the JPA ri itself blends itself perfectly into a leak others do not cover, small to medium sized objects which just need a clean and well thought out API without too much added functionality. If you need more, move up towards hibernate, or Toplink or KODO whatever, you dont have to change the code, all of them implement the JPA Apis as well.
  60. Obviously the RI is good: it is Toplink.
    It would be strange for Oracle to promote something different.
    Guido


    No one is arguing that the JPA RI is bad.
    Me too !! I was just saying that I find quite normal for Oracle to promote its own product (that is the RI too). So, taking into account Oracle customers only, it is reasonable to say that "EJB 3 has penetrated the market", either true or not in global terms. What else could Oracle do ? To promote JPOX over DB4O ? Guido
  61. Regarding Spring usage:
    I'm not that keen on trying to wrap a dependency (to JEE) with another dependency (to Spring). Even if it involves tons of lovely Spring configuration XML ;) So just say no to Spring and get a lightweight/annotation based DI framework just like Google Guice.


    So are you OK with wrapping or are you not OK with wrapping? I don't get it. Are you saying that wrapping is OK as long as the IoC engine uses annotations?

    I like Guice a lot. It's just not as mature as Spring. Guice would be a GREAT choice for an architecture. EJB 3.0 would be a GREAT choice for an architecture.

    My original point was not architectural comparisons, but rather market observations. Spring/Hibernate demand is going up. EJB in general going down. Guice, EJB 3.0 have not penatrated the market yet.

    Ok with wrapping of course, it all depends on the context of usage. In some environments (the company, your product etc.) it would be f.ex perfectly ok not to have any 3rd party dependencies or "frameworks" doing "cross-cutting concerns /aspects" for you. It all depends on the case at hand... I would prefer if there was a way to "annotate once-run everywhere" sort of. So that way my (let's say) @Stateful would work (could be used) in a different environment that just EJB 3.0. That's where Guice/Web Beans it think show promise... But then again as I've used EJB from day one on and off, I have no problems committing to a pure JEE architechture when needed. Neither does my company as long as there is an exit path for projects that need one...


    So does that mean that JSPs + JDO would be a bad architectural choice? The market comparison of JSP and JSF shows that JSP demand has been consistently high for the last two years, even as JSF demand has increased... You can draw your own conclusions from there.

    No I never said that, for some they might work (and JDO doesn't suck that bad, it's all ORM anyway = dead simple ;) ). Its my personal experience doing them and doing frameworks on top of them that they tend to become clumbersome where as something like Facelets pull ahead. BTW, your arguing with a "one trick pony" argument... I think using Google trends and similar is the wrong way to prove anything... F.ex it seems that I were I to buy a car Trabant would be better choice than a BMW 525: http://www.google.com/trends?q=trabant%2C+BMW+525&ctab=0&geo=all&date=all&sort=0 ;) (... or do you work in a recruiting firm? Why the obsession with job adds..?)
    EJB 3.0 => Good doesn't translate to !(EJB 3.0) => Bad
    MyOpinion("JSP Sucks") != "JSP Sucks"
    Who said it does? It should be crystal clear to any adult arguing/discussing in a forum that everything you write is a personal opinion, not the word of God... ...me thinks you should settle down, take a break from the keyboard and think before you post... -ioaalto
  62. So you like wrapping, depending on the context... Do you have any rules of thumb where you recommend wrapping over not wrapping?
    I would prefer if there was a way to "annotate once-run everywhere" sort of. So that way my (let's say) @Stateful would work (could be used) in a different environment that just EJB 3.0. That's where Guice/Web Beans it think show promise...
    "annotate once-run everywhere" (AORE?) can't really be a sort-of thing. It's more of a "Do or do not, there is no try" kind of thing. JPA appears to have succeeded with that philosophy. The jury is still out on that aspect of EJBs. Your AORE dream is shared, but the details don't add up to current or near term reality. I don't pay attention to individual unsubstantiated "likes" or "dreams" when choosing a technology. I do pay attention to "here's what I experienced" types of claims, and then try it out for myself. I do like standardized annotations in a big way. However, Guice/Web Beans have their own set of annotations that are not in-line with what the EJB 3.0 annotations accomplish. Guice uses plenty of proprietary annotations. It may include more standard annotations once WebBeans emerges. Guice still won't integrate as well as you may think it does. WebBeans will be the glue that makes it easier to get JSF and EJB3 to work together. Again, WebBeans a complementary technology to EJB3, not an implementation of it. It's also still in being "baked," meaning that it's still has some time before it's viable. WebBeans won't inherently fulfill an "annotate once run anywhere" philosophy... It will likely add on more annotations to the existing ones. I'm waiting eagerly for the results, but I'm not exactly holding my breath. BTW, what is going on on with JSR 299 (the WebBeans JSR)?
    But then again as I've used EJB from day one on and off, I have no problems committing to a pure JEE architechture when needed. Neither does my company as long as there is an exit path for projects that need one...
    It sounds like you may have something informative say based on your EJB3 experience. Please tell us about it.
    So does that mean that JSPs + JDO would be a bad architectural choice? [snip]
    No I never said that, for some they might work (and JDO doesn't suck that bad, it's all ORM anyway = dead simple ;) )
    I got to disagree with you there, buddy. ORM is hard for a beginner to get, especially if they come from a pure SQL/JDBC background. It's hard to translate some categories of complex tasks to workable ORM solutions. I'm really interested in why JDO was used to begin with. There were probably some great lessons there beyond "I like it." There are probably some good reasons why you think that "it sucks," but you haven't provided anything useful... The original question was "why should I give up my technology, I like it." Your response was "because your technology sucks." I was asking you to backup your claims.
    Its my personal experience doing them and doing frameworks on top of them that they tend to become clumbersome where as something like Facelets pull ahead.
    Sure, no one likes cumbersome frameworks. However, frameworks exist to add something unique. I'm eagerly waiting to be convinced that EJB3 can be used without external dependencies for both big and small projects.
    BTW, your arguing with a "one trick pony" argument... I think using Google trends and similar is the wrong way to prove anything...
    I was using job trends primarily to primarily to show where the jobs. I'll happily take back some of the tongue-in-check comments that I made about EJB. I'm extremely happy with the information I got about ejb server download trends and other interesting feedback. However, I will also happily argue with your assertion that "using Google trends and similar is the wrong way to prove anything..." Those kinds of assertions are just asking for a rebuttal. F.ex it seems that I were I to buy a car Trabant would be better choice than a BMW 525:
    http://www.google.com/trends?q=trabant%2C+BMW+525&ctab=0&geo=all&date=all&sort=0
    ;) So which technology is the BMW? :oP (... or do you work in a recruiting firm? Why the obsession with job adds..?) Nah, I'm a contract-worker, a.k.a. a consultant. I go from company to company implementing complex enterprise solutions.
    EJB 3.0 => Good doesn't translate to !(EJB 3.0) => Bad
    MyOpinion("JSP Sucks") != "JSP Sucks"


    Who said it does? It should be crystal clear to any adult arguing/discussing in a forum that everything you write is a personal opinion, not the word of God...
    I was calling your bluff on on your comment. You said that the other person's technology choice sucks without any proof whatsoever. That's just rude. I did wrote something myself, and look at where it got us... (comment #102 on this thread ;) Why state opinions at all then? Especially negative ones... It sounds like you have a lot of useful things to say, especially about your experience EJB3.
    ...me thinks you should settle down, take a break from the keyboard and think before you post...

    -ioaalto
    Beer in hand (figuratively). Negative opinions do inspire heated responses... Your (positive) EJB3 opinions are eagerly awaited. Did you use EJB on large or small projects? Were there problems? Did it help you write your application faster? What was the learning curve like?
  63. So you like wrapping, depending on the context... Do you have any rules of thumb where you recommend wrapping over not wrapping?
    Well, this is pretty hard for me to describe / explain, as we are obviously coming from different business environments. So I'll give a bit of info first: I work in a medium/small sized global firm in the telecom OSS area, I deal with mainly with technology not our products (been here just under 10 years). We do have quite a bit of specialized software that couldn't care less of EJB 3.0 or Spring Persistence (meaning don't need them)... But then again we deal with some operators that are 100 % into J2EE Application Server infra. Its a mixed bag of tech ranging from mainframes to J2EE Servers to what ever (and yes Java is not the only language, but I'm made of 66,6 % Java ;) )... I've used EJB (and EntityBeans with it) since they were available in IBM WebSphere as (don't remember exactly) 0.9/1.0 beta+ etc. something. Before that it was pure JDBC. To answer your question: Rules of thumb... Well when we know that we need scalability and can convince our customers that they need it too, we go to JEE Application Servers. With them you have a long history of doing scalable solutions and basically a guarantee that they will stay around for more than your normal small Open Source project (not implying Spring here, I think its here to stay). That's why going with pure EJB/J2EE on some of our solutions is acceptable and even preferable. That and because sometimes "add another layer of abstraction to solve a computing problem" doesn't work... There I said it! What a bold claim, eh? ;) But its true, even to the extent that f.ex when we where primarily doing IBM EJB (yes "IBM EJB" no spec is perfect), we went ahead and dug deep into WebSphere and did proprietary stuff/fixed memory leaks (against specs btw) with it to get to a place where we needed to be (IBM also has a habit of making the ugliest kludges and work arounds). Then when we needed to expand to other J2EE server we put in a little effort (mainly build system) and got Weblogic etc. on board. Then we lived happily ever after... :) Kidding, I just basically switched my concentration to other areas... But now I've lately come back to the "Hammer" called JEE (EJB 3.0 included).
    "annotate once-run everywhere" (AORE?) can't really be a sort-of thing. It's more of a "Do or do not, there is no try" kind of thing. JPA appears to have succeeded with that philosophy. The jury is still out on that aspect of EJBs.
    Yeah, *if* you are in a "tomorrow-to-production-state" situation (as you probably are)...I can dabble in whatever as I'm not producing products for customers(I have only internal customers; other architects /developers)
    Your AORE dream is shared, but the details don't add up to current or near term reality. I don't pay attention to individual unsubstantiated "likes" or "dreams" when choosing a technology. I do pay attention to "here's what I experienced" types of claims, and then try it out for myself.
    Fair enough...But instead of dreaming, you/anyone can DO something about it...
    I do like standardized annotations in a big way. However, Guice/Web Beans have their own set of annotations that are not in-line with what the EJB 3.0 annotations accomplish. Guice uses plenty of proprietary annotations. It may include more standard annotations once WebBeans emerges. Guice still won't integrate as well as you may think it does. WebBeans will be the glue that makes it easier to get JSF and EJB3 to work together. Again, WebBeans a complementary technology to EJB3, not an implementation of it. It's also still in being "baked," meaning that it's still has some time before it's viable. WebBeans won't inherently fulfill an "annotate once run anywhere" philosophy... It will likely add on more annotations to the existing ones. I'm waiting eagerly for the results, but I'm not exactly holding my breath. BTW, what is going on on with JSR 299 (the WebBeans JSR)?
    Maybe we need a "mapping framework" for Annotations..? (joke) Actually there needs to be a higher level of abstraction that would allow one to make a decision on what level you want to work with (with Web Beans or with some "ÜberAnnotation" for certain cross-cutting aspects) I don't know about the status, you'd have to ask Gavin or Bob Lee (thats the Google Guice guy) about that... There was an update in JavaOne (missed that but on my way to Barcelona for TSSJS) http://developers.sun.com/learning/javaoneonline/2007/pdf/TS-4089.pdf
    I got to disagree with you there, buddy. ORM is hard for a beginner to get, especially if they come from a pure SQL/JDBC background. It's hard to translate some categories of complex tasks to workable ORM solutions. I'm really interested in why JDO was used to begin with. There were probably some great lessons there beyond "I like it." There are probably some good reasons why you think that "it sucks," but you haven't provided anything useful... The original question was "why should I give up my technology, I like it." Your response was "because your technology sucks." I was asking you to backup your claims.
    Okay ORM maybe hard a first, but once you grok it then its easy. BTW, I didn't say JDO sucked (well maybe the binary preprocessing). I said that JSPs suck as I *thought* that as there are tzillons of web frameworks nowadays that something better that JSP would be used... I thought that it was common knowledge that JSPs suck (due to the hard debugging, lack of expression power in some areas, mixing logic with templating, fucked up component API =taglibs etc. Do you want me to continue...?)
    Sure, no one likes cumbersome frameworks. However, frameworks exist to add something unique. I'm eagerly waiting to be convinced that EJB3 can be used without external dependencies for both big and small projects.
    I was picking on JSPs <-- try it yourself, it so easy ;) ... But I don't need convincing of EJB 3.0 = the old saying somewhat applies to me: ”A known devil is better than an unknown god.” ... of course EJB 3.0 is not the devil even if someone thinks so... EntityBeans+DD XML have just spoiled the reputations somewhat. That's what inspired "Mr. Hibernate" to write it in the first place. But as you can hear from his comments/see from slides other parts of EJB have not been in the gutter ever... SessionBeans rock!
    I was using job trends primarily to primarily to show where the jobs. I'll happily take back some of the tongue-in-check comments that I made about EJB. I'm extremely happy with the information I got about ejb server download trends and other interesting feedback. However, I will also happily argue with your assertion that "using Google trends and similar is the wrong way to prove anything..." Those kinds of assertions are just asking for a rebuttal.
    Ah, forget it! It was perhaps a backlash at a person here in our company trying to prove (using Google trends) that PHP is somehow better than anything Java has to offer. Strongly disagree, but that turd has the ear of some suits...
    F.ex it seems that I were I to buy a car Trabant would be better choice than a BMW 525: http://www.google.com/trends?q=trabant%2C+BMW+525&ctab=0&geo=all&date=all&sort=0 ;) So which technology is the BMW? :oP
    Don't care actually, I'm a MB man myself (except that the insurance company took away my SL 500 once I had spinned off the road last fall :( ) Now I'm actually looking for a roadster with more power in it...
    (... or do you work in a recruiting firm? Why the obsession with job adds..?) Nah, I'm a contract-worker, a.k.a. a consultant. I go from company to company implementing complex enterprise solutions.
    Yeah, just messing with you. I actually read your blog: http://www.jroller.com/page/Solomon (if I was more of a nerd, I'd have a blog of myself too ;) ) BTW, if your into Martial Arts, check out my pics from UFC 72 at Picasa (<-- great software btw): http://picasaweb.google.com/ioaalto/IrlantiUFC72 (I'm the first guy from the top with a "islandic" / retarded look...) :)
    Beer in hand (figuratively).
    My holiday starts when I finish up this reply (but still going to TSSJS Europe), so I'll be heading towards a beer (non-figuratively), if you know what I mean..? Its summer here in Finland finally...
    Negative opinions do inspire heated responses... Your (positive) EJB3 opinions are eagerly awaited. Did you use EJB on large or small projects? Were there problems? Did it help you write your application faster? What was the learning curve like?
    We're actually trying to push EJB 3.0 and the whole JEE architecture in to areas in our company where it hasn't been yet. But f.ex about the learning curve, as you said ORM might not be easiest thing when the abstraction sometimes leaks (yeah I'm talking about f.ex Hibernate, "transitive persistence" indeed). We've actually currently have an architecture for Web GUIs that is Hibernate + JSF(Facelets) + couple of component libraries + some homebrew components and other stuff. We've had significant improvements of productivity compared to f.ex JSP-Servlet-JDBC and things have been great (no burning the midnight oil etc.). That's why going to EJB 3.0 for us is like switching from MB SL 500 to BMW 525: you're still driving a car but you maybe missing some features that were there (when you had an open topped roadster with 320 hp instead of an sedan that doesn't go as you would like it to go (... buu-huu...) ;) ). If you know Hibernate (or JDO I would assume) you'll get EJB 3.0 JPA in a sinch. As for the rest of EJB as I said its great for its purpose. Thats it! You've had some flak here, but its nice to see you can deal with it reasonably well and you seem intelligent enough to have I nice conversation with... You can reply, I'll check it out next Monday before I'm of to Barcelona.. I'm off to get that beer! ( it's actually "Juhannus" -Midsummer festival here so beer is everywhere ;) ) "Kippis!" == "Cheers!" (well almost) (no ORM joke or "object/JVM identity" != "persistence identity" pun here) -ioaalto
  64. very strange: all of us know that ejb new persistence nearly equal hibernate and spring is a very thin wrapper around it,so this is not relevant in the ejb3 era u may compare ejb persistence against spring jdbc or iBatis or jdo ,not spring+hibernate against ejb3, in the remaining areas (other than persistence) it's well known that spring model is superior in aop and interception(espesially in spring 2) and spring transaction is much better,and the message driven pojo in spring is really wonderfull actually the spring emulated most of the services and syntax of ejb3 in pitchfork project, but it is of low interest to spring community as the spring model IS SUPERIOR
  65. It was already well-established three years ago that CMP entity beans had not succeeded as a persistence programming model, which is why JPA was introduced. It appears the author has just figured this out. I also suspect the author is purposefully using the ambigious term "EJB" when he really should be referring to CMP entity beans.
  66. Hibernate does the CMP stuff... Spring handles the rest. Which technology would garner more attention on a resume, EJB or Spring & Hibernate?
  67. Ridiculous[ Go to top ]

    His own data shows that nearly twice as many job postings refer to EJB3 as to either Hibernate or Spring persistence. He combines the postings for Spring persistence and Hibernate to come to his conclusion. If you are going to learn both Spring and Hibernate, then why not also learn EJB3 as well and double your potential job opportunities? What is ridiculous is to treat these as exclusive opportunities. EJB3 and Hibernate3 are very close. If you know one you know 90% or more of the other. (I can't speak for Spring.) Mike Keith outlines the mutual development and evolution of EJB3 and Hibernate 3 here: http://www.jroller.com/page/mkeith?entry=the_ejb_3_0_hibernate
  68. EJB3 entity beans?[ Go to top ]

    Can somebody describe what Spring persistence is? I've never heard of it. I used Spring with JPA and was very productive with it. (But when I go for interviews nobody asks me about it.) As for EJB3, are entity beans still EJBs? They do not seem to have the same semantics with EJB 3 session beans.
  69. Re: EJB3 entity beans?[ Go to top ]

    We (the "Spring Persistence 101" book crew) use the term "Spring Persistence" to be ways of saving stuff to the database using the Spring Framework, JPA included. Here's a quote from Wikipedia about the term persistence:
    In computer science, persistence refers to the characteristic of data that outlives the execution of the program that created it.
    Most of the time in the Java world, persistence means a relational database. Spring supports a whole bunch of APIs/frameworks for database persistence, including Hibernate, IBatis, JPA and their own Spring JDBC. Part of my original assertion in all of this, was that employers don't really care about EJB3 or JPA. It's interesting that you're providing anectodal evidence.
  70. JPA entities are not entity beans[ Go to top ]

    They can be used in J2SE as well as Java EE. They require more developer management of persistence, but are much more flexible than EJB 2.x entity beans
  71. This appears to be an attempt to make a book containing outdated and stale content sound as if it was relevant. The premise is both unclear and misleading. If it was deliberate then shame on you. If not then you were not qualified to write the book.
  72. From a resume selling perspective, this is a ridiculous argument/question. I want developers who know how to evaluate alternatives, make choices and defend their choices. If the choice is made for them I want them to be able to quickly come up to speed on how to best implement it. The tools de jour are not that important unless all I’m looking for is a contractor for the short-term. Any company that is actually interested in hiring and retaining really sharp developers will focus on your demonstrated abilities to learn, think and problem solve. The ability to think abstractly and to model is also relatively rare and highly valuable. I’m amazed at the number of “OO” developers who don’t actually understand OO or OO analysis and modeling. If you’ve mastered that you rank pretty high in my estimation. I’ll get you some help with the platform and even the language. If you’ve been successful developing in a J2EE environment, it is highly likely that you’d be able to pick up Spring, Hibernate and other Java frameworks of that computing domain without too much difficulty. Beware of any hiring manager who doesn’t seem to realize that.
  73. The ability to think abstractly and to model is also relatively rare
    yes, indeed
    and highly valuable.
    Hmm, that depends on ability to sell the model to peers, upper and lower layers. Most of the time they simply cannot comprehend abstract models or switch contexts when crossing conceptual boundaries.
  74. The ability to think abstractly and to model is also relatively rare

    yes, indeed
    and highly valuable.

    Hmm, that depends on ability to sell the model to peers, upper and lower layers.
    Most of the time they simply cannot comprehend abstract models or switch contexts when crossing conceptual boundaries.
    I totally agree on the selling part of the job. You may come up with highly effective concept but there always seem to be somebody who do not like it because they don't understand conceptual models. These are often the same people who do not understand frameworks like Spring as "they don't see all the code". The rarity of people being able to think abstractly makes them valuable....only to rare people that can understand and appreciate the value of abstract thinking. Jacques Ledoux
  75. The ability to think abstractly and to model is also relatively rare

    yes, indeed
    and highly valuable.

    Hmm, that depends on ability to sell the model to peers, upper and lower layers.
    Most of the time they simply cannot comprehend abstract models or switch contexts when crossing conceptual boundaries.


    I totally agree on the selling part of the job. You may come up with highly effective concept but there always seem to be somebody who do not like it because they don't understand conceptual models. These are often the same people who do not understand frameworks like Spring as "they don't see all the code".

    The rarity of people being able to think abstractly makes them valuable....only to rare people that can understand and appreciate the value of abstract thinking.

    Jacques Ledoux
    Interesting. Personally I have found that software developers are much more interested in, and better at, abstract thinking, than a cross-section of the population. Theres plenty of people who know all the right design patterns, and who can express glorious abstractions in shiny powerpoints, but yet lack the ability to write anything but crappy code.
  76. William, you could not be more "right on"!! I tire of seeing resumes with a bunch of Alphabet Soup on them, but then the candidate cannot tell me about a technical decision they made or were involved in, and defend their choice. As technology evolves, smart developers will continue to learn the tool to solve the problem at hand. All the Alphabet Soup tells me is that they can take a test.
  77. The flip side is alphabet soup in the job specs... IMHO, Alphabet soup in the "buy" side of things has a bit more credibility.
  78. The problem with a focus on Hibernate is that the license is LGPL. Several organizations ban the use of libraries that are based on the LGPL when selling or OEMing software. After extensive analysis of the available products and their licenses I would recommend OpenJPA as persistence layer. Cheers, Justen Stepka http://www.jstepka.name/blog
  79. LGPL[ Go to top ]

    I know this is offtopic, but why LPGL is a problem? GPL is the one obliging you to open up your derived work, right?
  80. In my experience I used: - Hibernate + without JPA + spring inside Tomcat - Hibernate + JPA + spring inside Tomcat - TopLink + EJB inside Oracle AS - TopLink + JPA + spring inside Tomcat In my opinion the best solution (for simplicity, powerfully, testability) is Hibernate + Spring without JPA. I do not like very much JPA, I think Hibernate xml files (.hbm) are simpler and cleaner than @annotations. I like to use xml configuration files over @annotation, I think xml conf files are not so ugly to use, and, more over, let you to write POJOs cleaner. I do not like to annotate class with @Entity, or method with @WebMethod because if you tag your POJO with functionality (entity, staless bean, webservices) you link too much your data with the particular J2EE technology you are using; that's not the best solution. The best solution is to use a third xml file to link your POJO with the J2EE functionality. In this manner you promote best reusability and cleaner separation of concerns. Bye. Michele
  81. In my opinion the best solution (for simplicity, powerfully, testability) is Hibernate + Spring without JPA.
    I do not like very much JPA, I think Hibernate xml files (.hbm) are simpler and cleaner than @annotations.
    Errm, so why not just use metadata with JPA ? I know all of the people involved in the JPA spec decided to not publicise that part since annotations are allegedly sexier or something, but it does indeed support XML *or* Annotations *or* a mixture of both. http://www.jpox.org/docs/1_2/jpa/metadata.html In making any decision about what persistence process to use people should at least make that choice based on the key facts for their project http://www.jpox.org/docs/orm_relationships.html rather on what some attention seeking blogger posts.
  82. I am not a big fig fan annotations. I prefer not to leave the footprint of any specific technology inside source code. Also, I find it easier to browse xml instead of snippets of annotations scatterd all around
  83. Why, JEE haters, why?[ Go to top ]

    How many times have we seen these "Spring is superior to JEE"-type posts? The Java Enterprise stack is just that - a collection of useful technologies which should be used as needed. There's such a misconception out there that JEE is a heavy sledgehammer just looking to use too many resources where a simpler solution could fit. If you formed this opinion over 2 years ago, please, download the latest stable release of JBoss/Glassfish and do a HelloWorld. But guess what - you don't need to use ALL of it, just like you wouldn't incorporate every documented literary device in a 200-word essay. What JEE DOES provide is a neat Transactional context in which to wrap business logic. And if you're smart, you'll be putting that logic in POJOs and exposing methods as needed. You get injection. You get XA-aware transactions. You get fast prototyping and compile-time constraints with annotations. And you can override in XML. So when it comes to Spring Persistence, which is really just JPA plugged in - how is this any different from EJB3 Entity Beans, which also employ JPA and Hibernate/TopLink implementations under the hood? We're all doing the same stuff, really. I promise. S, ALR
  84. Proactive analysis?[ Go to top ]

    Solomon Duskis, enterprise developer and co-author of the upcoming book Spring Persistence 101 Bill Burke, enterprise developer and co-author of the already released book O'Reilly's EJB 3.0 urges engineers interested in enterprise development to focus their energy on learning EJB 3 and JPA rather than legacy Spring and Hibernate. LOL, proactive analysis?
  85. Re: Proactive analysis?[ Go to top ]

    LOL, proactive analysis?
    Umm... that's provocative, not proactive. It provoked you to respond, didn't it? I honestly didn't expect my blog entry to get this far, but I'm glad it did. This topic is still clearly up for debate. My point is that market research is important in picking a technology to learn, especially for a novice. For example, take a look at the Indeed market data. Job keyword trends and Salary by keyword. The trends for EJB in general are downward; Spring and Hibernate both have upward trends. However, you'll probably get paid about the same for both sets of technologies. The demand is up for Spring and Hibernate and the supply is still likely to be limited, although I don't have proof of that last part. There are very, very few EJB 3.0 and JPA jobs, but you may get paid a bit more if you find that really, really rare job that requires EJB 3.0 or JPA. I have no doubt that the rarity will change, but the big question is "when?"
    Bill Burke, enterprise developer and co-author of the already released book O'Reilly's EJB 3.0 urges engineers interested in enterprise development to focus their energy on learning EJB 3 and JPA rather than legacy Spring and Hibernate.
    I've shown the Indeed data and admit to a skewed interpretation in the favor of Spring/Hibernate which is the thrust of my upcoming book. However, I did have logical conclusions based on market data... Can you do the same for EJB 3.0? The logic isn’t there now, but how much time will go by before it takes off? Won't a developer familiar with "legacy" Hibernate be able to pickup JPA? I do own "Pro EJB 3", Mike Keith's book. Learning EJB 3.0 will be of great advantage in the future. However, I still think that the market forces for picking up Spring and Hibernate skills are exceedingly strong compared to alternatives, again especially for a novice. As far as the book is concered, we are trying to figure out how to differentiate our book... but we think we'll do OK by focusing on the basics of persistence with IoC in a small, easy to read book. I became more in awe of those who actually completed books. I humbly ask for help from anyone who actually wrote a book. I have taken the comments here at The Server Side really seriously.
  86. EJB3 momentum[ Go to top ]

    The longer the Spring is better than EJB3 debate goes on, the more out-of-touch those protagonists seem: with Glassfish, Geronimo, WebLogic, Oracle, and JBoss, what part of the Java-ecosystem is missing EJB3 support? Of course, there is some Spring support here-and-there, but pulling up dice.com numbers to validate a point is only self-fulfilling for the products/vendors that have previous installed bases, not recently issued EJB3 products... What I think is funny is that Spring is a development framework, while EJB3 is a deployment architecture, where app servers come in to play...there may be lots of development teams attracted to Spring, but ultimately in order to bring it to a revenue-generated model, where developers make money, it has to be deployed, so there may be initial interest in frameworks, but how can it sustain itself without apps on the Web that are Spring-associated... One of the things that has never been clear to me from all of the Interface21-hype is how they make money, and how, after the VC funding is gone, their revenue model attracts corporate deployment funding...I know the in vogue manner of Java start-ups, and all Google-facing start-ups is to get bought out, and cash in their initial investment...but without a revenue model, what does it bring to the table? I like Sping for a strategic investment from a major vendor (or 2) to compete with JEE in the mid-to-longish term for control of corporate development IT, but it doesn't seem to me to be a deployment story until one of said major vendors abandons EJB3+ deployment capabilities in favor of Spring...I am sorry to be conventional wisdom-based here, but charting career paths vis-a-vis a purported advantage in the job marketplace is a shoot-the-moon strategy when most vendors have already made their bets... Basically, I am daring Oracle or BEA to man-up and take the Spring challenge, and then we'll have a true competitive offering that begs the question: EJB 3 or Spring...until then, this is risky speculation...
  87. Re: EJB3 momentum[ Go to top ]

    Oracle, BEA and IBM are all hedging their bets by adding Entrprise OSGi support. Spring-OSGi will likely be ready for primetime within the next year.
  88. Re: EJB3 momentum[ Go to top ]

    Basically, I am daring Oracle or BEA to man-up and take the Spring challenge, and then we'll have a true competitive offering that begs the question: EJB 3 or Spring...until then, this is risky speculation...
    Oracle's Statement of Direction for JDeveloper and Oracle ADF mentions Spring 2.0, so maybe it's coming!
  89. Re: EJB3 momentum[ Go to top ]

    What I think is funny is that Spring is a development framework, while EJB3 is a deployment architecture, where app servers come in to play
    This is why the Spring guys are so desperate for OSGi. They have *NO* kernel. It is just not possible to use Spring alone to bootstrap production environments. A kernel does a bit more than be just a bean factory.
    One of the things that has never been clear to me from all of the Interface21-hype is how they make money, and how, after the VC funding is gone, their revenue model attracts corporate deployment funding
    This ambiguity is related to the long time annoyance I have of the Spring thought leaders. Take this guy's book "Spring Persistence 101". Spring is not a persistence solution, its a thin wrapper around JDBC, Hibernate, or JPA, something that is a few classes in any Java EE vendor's EJB3 implementation. Spring JMS, again not a messaging solution just a thin MDB clone. The list goes on, Spring Transactions, Spring OSGi. No solutions, just thin value-add wrappers. Pure value-add, zero core services/solutions. Where's the beef? Don't get me wrong, I'm glad the Spring movement has been successful. EE needed a kick in the butt. EE 5 helped a lot, but EE 6 (or OSGi) needs to bring the Interface21 guys to the table and start standardizing all the integration innovation that has been done in the Spring community so we're all not screwed when an Oracle scoops up I21 when they run out of money. Bill
  90. Re: EJB3 momentum[ Go to top ]

    No solutions, just thin value-add wrappers. Pure value-add, zero core services/solutions. Where's the beef?
    The core of Spring is the DI/AOP container (all the Spring thin wrappers are built on top of it & JEE). Is it beef? I don't know. But dotNET has been successful without DI and AOP.
  91. Re: EJB3 momentum[ Go to top ]

    BEA already supports Spring
  92. either...or[ Go to top ]

    The support from BEA is for both Spring and JEE, apparently is what I read, if its on edocs, and I have taken notice of their development tools strategy around Spring, but it still begs the question of why go to Spring when u have JEE5 and EJB3... I will happily answer that question for the BEA folks: it gets Sun and Glassfish out of the driver's seat, and, no, I will not be impressed by Eric's dice.com numbers of the irrelevance of Glassfish, or another one of your graphs about Spring's impending dominance... So to me, its a question of where do you want to make your bets, and as u have correctly pointed out, Oracle and BEA in particular are making bets around Spring, primarily to force Sun's hand on a number of issues, whether or not they are successful is anyone's guess.... Right about now, I suspect Cameron is writing a response that there is no conspiracy theory, that everyone loves everyone in app server land, and that Spring is purely complimentary to JEE - - I don't buy it... It's a fork of the standard, and whether or not there is enough momentum to sustain development team interest in it remains to be seen, though antecdotal evidence suggests it is making inroads...again, I see the EJB3 movement coming to a head and sides being taken, and lines being drawn, and competition to set in... Until then, we can all presume that Spring will be a player, but without a real competitive front, nothing has been proven out...
  93. Re: EJB3 momentum[ Go to top ]

    What I think is funny is that Spring is a development framework, while EJB3 is a deployment architecture
    I thought maybe I was just different because I didn't understand all the Spring hoopla. Is there really a need for complex and cumbersome app servers if all you need is Spring and Hibernate running on Tomcat?
  94. Re: EJB3 momentum[ Go to top ]

    I thought maybe I was just different because I didn't understand all the Spring hoopla.
    It took me a while to really "get" IoC in general. Bob Lee's Guice video has plenty of points, some of which are likely to resonate. The Spring hoopla is based on the IoC core and the infrastructure to develop an end-to-end application using IoC. Is Spring technically "better" than an EJB 3 infrastructure? I would venture to say that topic is up for debate and will continue to be debated for a while.
    Is there really a need for complex and cumbersome app servers if all you need is Spring and Hibernate running on Tomcat?
    We run Tomcat and Jetty in development, and WebSphere (a.k.a Web's Fear) in production. We use WebSphere for its deployment capabilities, clustering, and transactional environment. The internal application architecture is one of many aspects of choosing a server architecture. Hope this helps
  95. Re: EJB3 momentum[ Go to top ]

    Sorry Solomon - my comments were tongue in cheek - I get dependency injection and am using Spring. However, until EJB is removed from the JEE architecture it seems to me foolhardy not to at least have some understanding of the rationale for the container whatever "momentum" is flavour of the month.
  96. Re: EJB3 momentum[ Go to top ]

    Sorry Solomon - my comments were tongue in cheek - I get dependency injection and am using Spring.
    Hopefully the link will help someone else... :)
    However, until EJB is removed from the JEE architecture it seems to me foolhardy not to at least have some understanding of the rationale for the container whatever "momentum" is flavour of the month.
    +1 One should know the JEE architecture well. Spring runtime depends on the JEE container... It also integrates with EJBs to some extent. However, Spring is hardly the "soup du jour."
  97. Re: EJB3 momentum[ Go to top ]

    Sorry Solomon - my comments were tongue in cheek - I get dependency injection and am using Spring.


    Hopefully the link will help someone else... :)

    However, until EJB is removed from the JEE architecture it seems to me foolhardy not to at least have some understanding of the rationale for the container whatever "momentum" is flavour of the month.


    +1

    One should know the JEE architecture well. Spring runtime depends on the JEE container... It also integrates with EJBs to some extent.

    However, Spring is hardly the "soup du jour."
    Do you mean that spring doesn't in a J2SE env ? Guido
  98. Re: EJB3 momentum[ Go to top ]

    Do you mean that spring doesn't in a J2SE env
    Spring doesn't have to depend on a JEE server, but can be configured to take advantage of an JEE server. Spring can be configured to run in JSE environments and still have plenty of entrprise features. The same codebase can be configured to run in either "standalone" mode or in server mode. We've run our Spring applications from J2EE servers, JUnit tests, cron jobs, and even Swing applications... For example, we switched our database pool configuration between JNDI lookups in a JEE environment and open source standalone connection pools in JSE environments
  99. I have completely abandon Spring when I developing webapplications. I'm now using JBoss Seam, EJB3 and JSF - Gavin & Co. have done a great work for JBoss Seam and of course Hibernate :-) I still think Spring is a great framework, but I don't need it for webapplications when I have the JBoss Seam, EJB3 and JSF cocktail.
  100. I have completely abandon Spring when I developing webapplications.
    I'm curious as to why you did that...
    I'm now using JBoss Seam, EJB3 and JSF - Gavin & Co. have done a great work for JBoss Seam and of course Hibernate :-)

    I still think Spring is a great framework, but I don't need it for webapplications when I have the JBoss Seam, EJB3 and JSF cocktail.
    It does sound like the concktail has been getting more palatable. You're in a position to objectively compare and contrast the technologies... I'm interested in hearing about your experience.
  101. It is incorrect to make a broad statement that [QUOTE]Spring and Hibernate both have a tremendous demand, simply because they serve their purpose in a simpler way than EJB[/QUOTE]. Spring is really "glue-code". And Spring certainly encourages more modular and therefore more testable code. Which is not to say that you can not design modular and testable code without Spring. And certainly Spring doesn't do everything. In particular it is important to note that: a) EJBs come in two flavors: Session and Enterprise b) EJB 3 does away with all the problems of earlier EJB versions simply by offering the 'lighter' implementation delivered by Hibernate, while at the same time going one step further and exposing the Data Access Layer via a unified, generic API - the JPA. Session EJBs provide a container-configurable, easy to integrate, service abstraction. In a clustered, high-availability J2EE application, the easy integration (clustered, load-balanced/fail-over) of a Session EJB as a service is simply unbeatable by Spring. Of course you could do the same with Spring - just not as easily. EJB3 is arguably better integrated in a modern J2EE app server than a Spring/Hibernate combination. EJB3 can also be used in 'light' implementations with no J2EE Container dependency. EJB3 additionally offers the unbeatable value of being able to replace your Persistence Provider with any JPA provider. Hibernate may be good today - tomorrow, there could be a better solution. EJB3 gives you the flexibility of low switching costs. Blanket statements and categorisations are always dangerous. They are indicative of a closed mind. The J2EE stack is constantly evolving. Spring and Hibernate were great at some point of the Java evolution life-cycle - they pushed the J2EE stack towards more flexible and lighter APIs. It is important to view each of these libraries as a component that provides certain features. And it is important to select the component that most closely matches the features required to solve the problem on hand. It is wrong to generalise and say Component A is better than Component B. Even when there is an overlap in features.
  102. It is incorrect to make a broad statement that [QUOTE]Spring and Hibernate both have a tremendous demand, simply because they serve their purpose in a simpler way than EJB[/QUOTE].
    You're right.... My statement was overly broad and tongue-in-cheek. So it begs the question. Why is EJB trending downward and both Spring and Hibernate are steadily trending up in the job market?
    In a clustered, high-availability J2EE application, the easy integration (clustered, load-balanced/fail-over) of a Session EJB as a service is simply unbeatable by Spring. Of course you could do the same with Spring - just not as easily.
    Are you really sure of this? Perhaps not by Spring proper... but there are plenty of third parties that support this functionality. Easily.
    EJB3 is arguably better integrated in a modern J2EE app server than a Spring/Hibernate combination. EJB3 can also be used in 'light' implementations with no J2EE Container dependency.
    How does one define better? How can this argument be proven?
    EJB3 additionally offers the unbeatable value of being able to replace your Persistence Provider with any JPA provider. Hibernate may be good today - tomorrow, there could be a better solution. EJB3 gives you the flexibility of low switching costs.
    JPA is making a difference in other architectures as well. JPA has taken on a meaning all its own. This same argument can be made for Spring 2.0+.
    blanket statements and categorisations are always dangerous. They are indicative of a closed mind.
    Fair enough. Is this quote a blanket statement?
    The J2EE stack is constantly evolving. Spring and Hibernate were great at some point of the Java evolution life-cycle - they pushed the J2EE stack towards more flexible and lighter APIs.

    It is important to view each of these libraries as a component that provides certain features. And it is important to select the component that most closely matches the features required to solve the problem on hand.

    It is wrong to generalise and say Component A is better than Component B. Even when there is an overlap in features.
    Again, fair enough. My original straight job based observations still stand... I've been getting a muddled response from the EJB 3 guys. "It's here and it's strong." "It's still in progress, give it time." In addition what other metrics can be used to determine "betterness?" What really is an "apples to apples" comparison with these technologies?
  103. Quite honestly I think if you are hiring for EJB and you have in front of you an excellant candidate who is skilled in 'Spring persistence', or, if you hiring for 'Spring persistence' and you have in front of you an excellant candidate who is skilled in EJB(3) then you'd be a fool not to hire them. Ok I know unfortunately there are alot of fools around...
  104. Quite honestly I think if you are hiring for EJB and you have in front of you an excellant candidate who is skilled in 'Spring persistence', or, if you hiring for 'Spring persistence' and you have in front of you an excellant candidate who is skilled in EJB(3) then you'd be a fool not to hire them.

    Ok I know unfortunately there are alot of fools around...
    :) Interesting... but what happens if you have a Spring/Hibernate job and you have one great candidate skilled EJB3 and one skilled in Spring/Hibernate... which would you choose? I'm not convinced the keyword based job postings or resume searches are foolish. How would you search through thousands of resumes or jobs? Heck, how would you search through billions of on-line documents? You'd probably do a keyword search. Is that foolishness? Sure, you could search for ORM/Hibernate/Toplink/JDO/Entity Beans... But you're more likely to start your search for exact matches. You can't easily search for "smart guy."
  105. :) Interesting... but what happens if you have a Spring/Hibernate job and you have one great candidate skilled EJB3 and one skilled in Spring/Hibernate... which would you choose?
    All things being equal you would probably choose the Spring/Hibernate candidate. The point being though is that either candidate would be worth hiring. Keywords are obviously necessary but excessive use of them for filtering I think means you lose potentially great candidates. And great candidates are not easy to find :)
  106. :) Interesting... but what happens if you have a Spring/Hibernate job and you have one great candidate skilled EJB3 and one skilled in Spring/Hibernate... which would you choose?


    All things being equal you would probably choose the Spring/Hibernate candidate. The point being though is that either candidate would be worth hiring.

    Keywords are obviously necessary but excessive use of them for filtering I think means you lose potentially great candidates. And great candidates are not easy to find :)
    I'll add another dimension to this. Do you think that the EJB3 candidate will even be called in for an interview? There are probably hundreds of available candidates that will match a Spring/Hibernate keyword search. Wouldn't those be a better starting point for recruiters than Toplink/EJB3/JDO candidates? Yes, good candidates are really hard to find... but if there is an equal chance of finding a good candidate by any search criteria, recruiters/managers/tech leads are more likely to try to look at the resumes that match the job the best. It's very difficult to find "great candidates" (quality) using searches, but its done anyway... IMHO, quantity is subjective anyway. Keyword searching is the best way we've got for the quantity of jobs and candidates that are out there.