Opinion: EJB 3.0 - drop the baggage from previous versions!

Discussions

News: Opinion: EJB 3.0 - drop the baggage from previous versions!

  1. The EJB 3.0 BOF at last week's TSS Java Symposium I raised the question as to why the spec committee felt the need to carry along all the baggage of the previous specifications with each new version. I suggested that the community (and vendors) would be better off if supporting old versions of specifications were up to the vendors and not mandated by the specification committee.

    While the support in the crowd was unanimous, there appeared to be little movement on the part of the attending specification committee members.

    The reason stated for this (in an after-session discussion) was that the J2EE brand would be harmed if vendors dropped support too quickly. My thought is that this is highly unlikely - what would be far more likely is that the WebSphere, or WebLogic, or JBoss brands would be harmed by a small percentage of customers that were unwilling to upgrade.

    Face it, most customers - at least the ones that pay the bills - don't give a rip at this point about J2EE, they buy WebSphere or WebLogic, and if they are even aware of J2EE, they look at J2EE as a portability mechanism; a "safe out" in case the vendor relationship sours. If the spec is upgraded and the vendor doesn’t provide backwards compatibility, the uproar will be on the vendor and not on the spec.

    Why am I so worked up about this? Because keeping 2.1 compatibility; actually, setting the expectation that all future versions will support all past versions, becomes a VERY effective club that current vendors can use to prevent new entrants into the J2EE appserver market. Providing backwards compatibility is not only costly for a new entrant, its almost entirely unnecessary as new development will almost certainly be using EJB 3.0.

    If the spec committee is adamant that old versions be supported, at a minimum they could cut the cord from EJB 3.0 to EJB 2.1, let EJB 3.0 be a nice thin specification (shaving off hundreds of pages from the spec, probably) and allow the J2EE specification to require EJB 2.1 and EJB 3.0 both. That way a lightweight container could fully implement EJB 3.0 even if it doesn't achieve full J2EE certification.

    **Editors Note**: On a related note - a live survey to all the attendees of TSSJS was done during the conference and one of the questions was whether EJB 2.1 compliance should be optional - 80% said yes.

    Threaded Messages (68)

  2. On the point about allowing new entrants into the appserver market (both commercial and open source) there may be a solution.

    In the past, JMS vendors have labelled themselves J2EE compliant, and said that they were able to achieve this because they bundled their product with another vendor's full J2EE implementation so that they could past the TCK and claim compliancy.

    Wacky idea: Perhaps this approach could be replicated in this context - allowing new entrants implementing only EJB 3.0 features to become compliant by temporarily bundling with J2EE 1.4 certified servers like JonAS/JBoss (which have EJB 2.1) when doing the compatibility tests.
  3. A potential solution[ Go to top ]

    Floyd -

    Also, this is where the likes of Spring could come in:

    GeronoSpring: Developers can use Spring and claim EJB 3

    Basically, this is leveraging vendors as you mention.

    Dion
  4. Why doesn't the vendor-dominated spec committee allow EJB 2.1 compliance to be optional?
    Because keeping 2.1 compatibility... becomes a VERY effective club that current vendors can use to prevent new entrants into the J2EE appserver market.

    Mr. Dawson, I believe that you have answered your own question.
  5. Why doesn't the vendor-dominated spec committee allow EJB 2.1 compliance to be optional?

    Vendor-dominated spec committee?!?

    Last time I looked, out of the 30-40 members of the EC, less than five (more like three if you only count those that have significant market share) work for a company that sells an EJB container.

    --
    Cedric
  6. Vendor-dominated spec committee?!? Last time I looked, out of the 30-40 members of the EC, less than five (more like three if you only count those that have significant market share) work for a company that sells an EJB container.-- Cedric


    I think you've miscounted and you have missed the point. I count 32 members of the Expert Group. To my knowledge, the following are in the app-server business:

    1. Sun
    2. Novell
    3. Sybase
    4. BEA
    5. Borland
    6. Oracle
    7. IBM
    8. IONA
    9. Pramati
    10. JBoss
    11. Apache

    (I am guessing that the Apache rep(s), like the JBoss rep(s), sell support services for EJB application servers. I am happy to be corrected if this is not the case)

    Many of the other companies on the committees have significant marketing arrangements with the established EJB vendors, and Sun has final veto power over questions like, "Do you have to be backward-compatible to be compliant?"

    So, I stand by my opinion that this is a 'vendor-dominated' spec committee and that is the primary driver behind requiring backward compatibility.

    Since you disagree, Cedric, can you please explain why you feel that the EG does not allow backward compatibility to be optional?
  7. 12. Tmax Soft

    Never heard of these guys, but looks like they are a J2EE app-server vendor as well.
  8. Corby :
    To my knowledge, the following are in the app-server business:1. Sun2. Novell3. Sybase4. BEA5. Borland6. Oracle7. IBM8. IONA9. Pramati10. JBoss11. Apache(I am guessing that the Apache rep(s), like the JBoss rep(s), sell support services for EJB application servers.

    Risking providing Hani w/ more material...

     I think it's not fair to consider Apache being in the app-server business, as the ASF is a 501(c)3 non-profit and is not in any business or competing with anyone.

    Yes, as part of my day job at Gluecode, I am in the support business. However, the ASF has been on the JCP EC since the beginning, and has been represented by multiple people over the years, none of whom were or are in the EJB business.

    When I worked to get Geronimo to Apache, I wasn't in that business, and it's conceivable that I won't always be in the business, nor the ASF always represented by me.

    As to the point of the thread (something I also wanted to stay out of...), I think that backwards compatibility is important in order to protect the existing investment in the platform by users, and encourage users that Java and J2EE is a safe place to devote development resources. That said, I do feel there can be a compromise and have parts of the spec be end-of-lifed for upcoming versions of the spec or vendor and OSS project deliverables as long as users have a clear roadmap and a commercially reasonable chance to upgrade.

    <joke>
    After all, if you get rid of the backwards compatibility of EJB3, what are you left with? JDO2?
    </joke>

    Really. That was a joke :)

    I think there are good things in the new EJB3 spec, but do wonder if we're once again behind the curve and instead of playing with annotations, be focusing on how AOP can help. Ask the Spring folks... :)

    geir
  9. EJB 3.0 and Geronimo[ Go to top ]

    I sometimes wished that the Geronimo team just focused on getting J2EE 1.5 only even if it is a moving target at the moment. This would reduce their code base. Then provide the older versions as extra modules that could be added onto the container and be developed as needed.

    The only problem with these multiple jars is the dependency hell that would ensue. I wish there was a way to say if I load up jar X it would load up jar Y, Z, A, B as needed. Oh well that would be a J2SE 5+x.0 feature I guess. http://www.livejournal.com/users/trajano/26052.html
  10. Yes, as part of my day job at Gluecode, I am in the support business. However, the ASF has been on the JCP EC since the beginning, and has been represented by multiple people over the years, none of whom were or are in the EJB business.When I worked to get Geronimo to Apache, I wasn't in that business, and it's conceivable that I won't always be in the business, nor the ASF always represented by me.

    Your position at your current company is clearly a conflict of interest. You should step down and let somebody else with a bit more integrity from Apache take over. Somebody like Dims (Davanum Srinivas) from Apache AXIS, for example, seems to have a much better ability to bring together communities than the divisiveness that you tend to foster.

    Bill
  11. Bill :
    Yes, as part of my day job at Gluecode, I am in the support business. However, the ASF has been on the JCP EC since the beginning, and has been represented by multiple people over the years, none of whom were or are in the EJB business.When I worked to get Geronimo to Apache, I wasn't in that business, and it's conceivable that I won't always be in the business, nor the ASF always represented by me.
    Your position at your current company is clearly a conflict of interest.

    Once again, you simply assert that but give no evidence. Please point out one example where I have displayed any conflict of interest. Are you saying that because I work for a company that builds products based on Apache open-source that I have a conflict of interest because I represent Apache? IBM builds products based on Apache open-source. Sun builds products based on Apache open-source. Heck, a good bit of the JBoss app server is Apache open source.
    You should step down and let somebody else with a bit more integrity from Apache take over. Somebody like Dims (Davanum Srinivas) from Apache AXIS, for example, seems to have a much better ability to bring together communities than the divisiveness that you tend to foster.Bill

    Please, Bill, give a single example of where I didn't act on behalf of the ASF. Just one.

    geir
  12. conflict?[ Go to top ]

    Geir wrote:
    Once again, you simply assert that but give no evidence. Please point out one example where I have displayed any conflict of interest.

    Fact: As stated in your response to jBoss, Geronimo took ideas (that were not patented) from jBoss intro Gernimo.

    And now ... would you consider this memo a conflict of interest? (where you recommend to Apache that it is OK to remove from CVS trace the word jBoss in Geronimo, that would trace the origin of code )
    http://www.mail-archive.com/general at incubator dot apache dot org/msg02126.html

    That to me is evidence of conflict of interest! Would you now step down and give chair to... Nicola?

    .V
  13. conflict?[ Go to top ]

    What does this have to do with Gluecode and the JCP, Vic? C'mon. Stay on topic. This was last weeks strawman.

    You're supposed to be attacking me for not voting against JDO, Vic.

    Vic :
    Geir wrote:
    Once again, you simply assert that but give no evidence. Please point out one example where I have displayed any conflict of interest.
    Fact: As stated in your response to jBoss, Geronimo took ideas (that were not patented) from jBoss intro Gernimo.And now ... would you consider this memo a conflict of interest?

    Oh please. We've been through this. We're still waiting for your detailed summary and conclusion, btw.
    (where you recommend to Apache that it is OK to remove from CVS trace the word jBoss in Geronimo, that would trace the origin of code )http://www.mail-archive.com/general at incubator dot apache dot org/msg02126.htmlThat to me is evidence of conflict of interest! Would you now step down and give chair to... Nicola?.V

    Re the above, yes, it was ok to remove it. Read the whole thread. It was Jason's personal string util code. When he worked on JBoss, he used it in JBoss, and when he came to Geronimo, he used it there. He committed the wrong version. At the time, he realized his mistake, and not knowing what to do, just removed the archive and tried it again. This was a mistake on his part - he should have just committed a fix, and this was explained to him. It was just a matter of not knowing procedure.

    geir
  14. conflict?[ Go to top ]

    Stay on topic. geir

    You asked for an example of conflict of interest in this thread for some reason; and I linked an example of something I consider confilict of interest, where in that linked email you dealt w/ jBoss code, GlueCode developer and Apache hat that may have lead to your employment w/ Gludecode.
    It's not cool, imo; just don't bring it up, it does not help you.

    It has nothing to do w/ this thread!

    .V
  15. conflict?[ Go to top ]

    Vic :
    Stay on topic. geir
    You asked for an example of conflict of interest in this thread for some reason; and I linked an example of something I consider confilict of interest, where in that linked email you dealt w/ jBoss code, GlueCode developer and Apache hat that may have lead to your employment w/ Gludecode.It's not cool, imo; just don't bring it up, it does not help you.It has nothing to do w/ this thread! .V

    Did you even read the thread, or just see a chance to take a shot at me and did so? Are you suggesting I could see into the future, and know that dealing with the JBoss letter would in the future help me get a job at a place I hadn't yet heard of?

    Do you wear a tinfoil hat when dreaming this stuff up?

    It's not a conflict of interest - the things you mentioned were ASF decisions, which I supported, but not my sole decisions. The JBoss letter was written to the ASF, and the ASF responded. Clear? Can we put this behind us now?

    Maybe we can go back to making fun of my name. That was more interesting than this nonsense.

    Sincerely,

    Gehr
  16. Bill :
    Your position at your current company is clearly a conflict of interest.

    Let me try this another way, since my previous response might be too confusing for you. Please answer this question :

    How has my employer, Gluecode Software, directly benefitted due to actions I've taken on behalf of the ASF on the JCP EC?

    (And remember, I've only been at Gluecode since August, so my personal support of JDO and thoughts about EJB3, and the ASFs support of letting technologies compete were pre-existing positions and have no bearing on your antagonism towards JDO.)

    geir
  17. oh..this is going to . . .[ Go to top ]

    be a perfect fit in Hani's Summary.
  18. Yes, as part of my day job at Gluecode, I am in the support business. However, the ASF has been on the JCP EC since the beginning, and has been represented by multiple people over the years, none of whom were or are in the EJB business.When I worked to get Geronimo to Apache, I wasn't in that business, and it's conceivable that I won't always be in the business, nor the ASF always represented by me.
    Your position at your current company is clearly a conflict of interest. You should step down and let somebody else with a bit more integrity from Apache take over. Somebody like Dims (Davanum Srinivas) from Apache AXIS, for example, seems to have a much better ability to bring together communities than the divisiveness that you tend to foster.Bill

    This is rich (and unintentionally hilarious), coming from the most obnoxious, socially unskilled, divisive participant on these boards.
  19. fair enough[ Go to top ]

    This is rich (and unintentionally hilarious), coming from the most obnoxious, socially unskilled, divisive participant on these boards.

    FWIW, I don't disagree... I've tried to be more PC, but its just left acid in my stomach. Too many personalities here just irritate me so with their I'm-so-holy personas.
  20. Somebody like Dims (Davanum Srinivas) from Apache AXIS, for example, seems to have a much better ability to bring together communities than the divisiveness that you tend to foster.Bill

    This is an interesting recommendation especially since direct support of AXIS (Jboss.NET) in JBoss 4 and higher has been dropped in favor of JBossWS.

    http://www.jboss.org/wiki/Wiki.jsp?page=JBossWSFAQ
  21. At least five reasons:

    1. Microsoft will use it as a reason J2EE is indeed an unstable and immature technology. (IMO, they are actually right, but it does not matter because they will win eventually.)

    2. Removing backward compatibility will simply lower the bar of entry to this J2EE market. There are plentty of vendors here now, aren't there? App vendors, do you really want more to compete with you? Think sensibly.

    3. I don't use the EJB stuff whatsoever, so I don't care if the spec is huge and hard to understand. I don't have to read it, so you can just keep the stuff and add more and more.

    4. All we need is the J2EE marketing buzz anyway. So as long as there is one little thing in the spec that we can use, like Servlet, we will be able to advertise J2EE-based, -friendly or -compliant, without feeling guilty.

    5. The more complex the spec becomes, the higher value of J2EE expertise will be. Java is too easy; we need something more complex.
  22. .3. I don't use the EJB stuff whatsoever, so I don't care if the spec is huge and hard to understand. I don't have to read it, so you can just keep the stuff and add more and more.

    +1.

    jBoss admited were bad, no other vendor yet? Does anyone w/ experience think... I have thousands of concurent users, I should try EJB 1st, or do we all think opposite, like try SQL E/R based DAO!

    Maybe Geir has no value to Core Developers Network other than his seat, so it will take more pressure. What else can he do for them, bring them good press?

    .V
  23. Somebody like Dims (Davanum Srinivas) from Apache AXIS, for example, seems to have a much better ability to bring together communities than the divisiveness that you tend to foster.Bill
    This is an interesting recommendation especially since direct support of AXIS (Jboss.NET) in JBoss 4 and higher has been dropped in favor of JBossWS.http://www.jboss.org/wiki/Wiki.jsp?page=JBossWSFAQ

    I had lunch with Dims a few weeks ago. I liked him because he respected our reasons for forking, then ditching AXIS, and didn't take it personally. He tried to encourage us to get into other non-SOAP WS efforts at Apache even if we weren't going to use AXIS. He reminded me that there are good inviduals at Apache and that I shouldn't let the actions of a few individuals sour my perceptions of a whole organization. One thing he didn't convince me of was that ASL is a superior license though ;-p!

    Bill
  24. Why doesn't the vendor-dominated spec committee allow EJB 2.1 compliance to be optional?
    Because keeping 2.1 compatibility... becomes a VERY effective club that current vendors can use to prevent new entrants into the J2EE appserver market.
    Mr. Dawson, I believe that you have answered your own question.

    Just wanted to say that I am in the camp to drop the old stuff. Hopefully you saw me raise my hand when Tim asked this question at the BOF. Honestly, it is quite expensive for us to have to maintain the old stuff so that it runs against the TCK.

    I was talking to the Oracle guys at TSS about this. Both of us were saying that the idea that the EG doing this as a barrier to entry is kinda silly. If anything, J2EE needs MORE vendors, not less.

    Bill
  25. Just @deprecate[ Go to top ]

    I don't think we should just drop it. A lot of existing applications might still be using EJB 2.1 or worse EJB 1.1 and older specs. What they should just do is let be be marked as @deprecated so those who are using the older versions know which parts to upgrade.

    In the same note, there should be two jars rather than one for the J2EE spec. j2ee.jar and j2ee-classic.jar, where classic contains all the code that are to be deprecated. This way if we need a light weight version of J2EE, we just drop the j2ee-classic.jar from our classpath and see what breaks.
  26. Just @deprecate[ Go to top ]

    I guess my point was that the EJB 2.1 spec doesn't go away. Its still out there and valid for vendors to continue to support.

    But by not dragging it into EJB 3.0, its effectivly deprecated without having to officially do so (deprecation is something that Sun seems to have a very hard time doing - when was the last time they actually did deprecate something? Hashtable and Enumeration are still not deprecated despite having been replaced by Map and Iteration in 1.2).

    I liked what you advocated for the jar breakdown; forking the specification would provide pretty close to that.

    During the panel discussion on the last day Dion made the comment that we don't want EJB 9.0 being backwards compatible to EJB 1.0. Everybody including EJB 3.0 spec leads got a big laugh out of that, but that's the way we're headed at the moment.
  27. Let the vendors decide[ Go to top ]

    Hashtable and Enumeration are still not deprecated despite having been replaced by Map and Iteration in 1.2)

    The problem is, the Hashtable, Vector and Enumeration are so prevalent in many many organization's code base. Additionally, many of these legacy programming semantics are so spewn all over, coverting these to Map IF or Synchronized version of Map IF will require many man months, if not years, to convert them over.

    I guess, the same is true while using newer version App Server that still supports older specs. I have noticed after working at big organizations, they seem to replace the app server rather reasonably fast. But when come down to code, the prevailing motto is - If it aint broke, dont fix it!!

    So I suppose, there is little choice for the vendors to support the previos version of the spec. Of course, the newer version of the spec doesnt have to dictate any strategy for backward compatibility. I guess it should be upto the discretion of the vendor.

    My two cents
  28. If the spec committee is adamant that old versions be supported, at a minimum they could cut the cord from EJB 3.0 to EJB 2.1, let EJB 3.0 be a nice thin specification (shaving off hundreds of pages from the spec, probably) and allow the J2EE specification to require EJB 2.1 and EJB 3.0 both. That way a lightweight container could fully implement EJB 3.0 even if it doesn't achieve full J2EE certification.

    Are you asking for EJB 3.0 to drop just the requirement for supporting 2.x and 1.x EntityBeans, or stateless/stateful session beans as well? If you're looking for just the EJB3-style POJO persistence by itself, that is already being addressed via a separate persistence spec coming out of the same JSR-220 expert group as the EJB3 spec. The goal of that persistence spec is to be usable on top of just J2SE and it would not require a "container" (at least, not the way that J2EE defines a container). This was covered in an "Open Letter to Developers" that Sun issued a number of months ago and was discussed on TSS here).

    Randy
  29. What I'm advocating is the entire spec to be forked, including entity, message-driven, stateful, and stateless session beans.

    The goal is to be able to have a lightweight container that's fully EJB compliant without having to pull forward anything form the old model that's been clearly discredited. This includes not just the entity layer (which few people used anyway) but also the old lifecycle and deployment descriptor management.

    Just separating out the entity layer doens't provide anything in terms of getting a lightweight EJB compliant container... it just gets something that's "EJB-like" and that won't pass muster for deployment in many large organizations.
  30. Supports: Version 2.1, 3.0, 4.0, ...[ Go to top ]

    I agree with you Tim.

    Many technologies have vendors say:

    "I support version 1.0, and 2.0"

    others say:

    "I support version 2.0"

    The spec itself doesn't enforce the backwards compatibility.

    Not only is this "fine" in many cases, the current situation DOESN'T SCALE.

    EJB 12.0 (backwards compatible to 0.9)

    Dion
  31. What I'm advocating is the entire spec to be forked, including entity, message-driven, stateful, and stateless session beans.The goal is to be able to have a lightweight container that's fully EJB compliant without having to pull forward anything form the old model... This includes not just the entity layer (which few people used anyway) but also the old lifecycle and deployment descriptor management.Just separating out the entity layer doens't provide anything in terms of getting a lightweight EJB compliant container... it just gets something that's "EJB-like" and that won't pass muster for deployment in many large organizations.

    It sounds like you'd be interested in the lightweight POJO persistence spec then -- that's the closest thing to "forking" that's likely to happen. As the open letter outlines, this will not be called "EJB" but will be a standalone persistence mechanism that ideally could be used on J2SE as opposed to J2EE. The EJB spec in J2EE would build on this persistence support.

    On your comment about what would pass muster for deployment in large organizations, it's mainly the large organizations that have expressed concern about whether the EJB3 spec will include full support for deployment descriptors that are separate from the code, as an override to the code-based annotations. There's been a lot of feedback to the effect that deployment descriptors must continue to be supported.

    Randy
  32. POJO is a little old fashioned[ Go to top ]

    It sounds like you'd be interested in the lightweight POJO persistence spec then -- that's the closest thing to "forking" that's likely to happen. As the open letter outlines, this will not be called "EJB" but will be a standalone persistence mechanism that ideally could be used on J2SE as opposed to J2EE. The EJB spec in J2EE would build on this persistence support.

    Probably there are better names than "J2SE/J2EE POJO Persistence", e.g. JOP (Java Object Persistence) or JRM (Java Relational Mapping).
  33. It sounds like you'd be interested in the lightweight POJO persistence spec then -- that's the closest thing to "forking" that's likely to happen. As the open letter outlines, this will not be called "EJB" but will be a standalone persistence mechanism that ideally could be used on J2SE as opposed to J2EE. The EJB spec in J2EE would build on this persistence support.

    Yes, the POJO spec will be nice, but its already slated to be released as a separate spec. That's not enough. I haven't used EJB persistence since a horrible failure with the 1.1 model, and I've grown increasingly discontent with the rest of the EJB specification over the years; the fact that it wasn't as awful as the Entity bean stuff just dragged it out.

    Finally, the EJB 3.0 looks better, like something I could use (though I know I could use Spring and roll my own, some of my larger customers will likely feel better on a production enterprise system based on a spec).
    On your comment about what would pass muster for deployment in large organizations, it's mainly the large organizations that have expressed concern about whether the EJB3 spec will include full support for deployment descriptors that are separate from the code, as an override to the code-based annotations. There's been a lot of feedback to the effect that deployment descriptors must continue to be supported.Randy

    I keep hearing this argument that customers want backwards compatibility. I agree becuase I happen to be one of them - I can't move a 3 million line codebase on a dime either. But that doens't make your case because my backwards compatibilty needs are satisfied whether or not its in the spec, because my current vendor will in all reality have to provide backwards support it either way.

    Again, I challenge you and anyone else who supports the status quo to provide evidence that customers who want backwards compatibility actually understand the difference (and care) whether its done by the vendor or required in the specification.
  34. Yes, the POJO spec will be nice, but its already slated to be released as a separate spec. That's not enough. I haven't used EJB persistence since a horrible failure with the 1.1 model, and I've grown increasingly discontent with the rest of the EJB specification over the years;
    Yeah, yeah...we know you think EJB has been a horrible failure, etc. Please tell us exactly why releasing the POJO persistence spec (or whatever name is better) as a separate spec would not be enough. At this point in the conversation it's looking like you're interested mainly in flailing against EJB and the J2EE specs in general.
    Again, I challenge you and anyone else who supports the status quo to provide evidence that customers who want backwards compatibility actually understand the difference (and care) whether its done by the vendor or required in the specification.
    For the same reason that customers like standards in general -- it gives them the flexibility to choose among different, competing implementations, knowing that as long as they write to the specification, their code will continue to run going forward. Having backwards compatibility in the spec gives customers a higher comfort level than promises from their current vendor alone. If you don't buy that argument, I guess you're free to develop and market your own application server and see how your customers feel about standards and backward compatibility. :)

    Randy
  35. Yeah, yeah...we know you think EJB has been a horrible failure, etc.
    Actually, the horrible failure I was referring to was my first EJB project, because the technology didn't work and we had to do major rewrites to replace all the Entity beans.

    But apparently there's a lot of agreement in the community that EJB has in many ways been a failure or EJB3 wouldn't be such a departure from previous specs.
    Please tell us exactly why releasing the POJO persistence spec (or whatever name is better) as a separate spec would not be enough.
    Because I'm not all that interested in the POJO spec in the first place. (I'm a satisfied hibernate user and I really don't need the POJO spec all that much - it will just make what I'm using "standard".) For me, the interesting parts of the EJB spec has always been the standard deployment model (which EJB3 improves upon) and the ablity to provide a clean service API and have declarative security and transactions. What I want is a lightweight EJB specification so we can have a lightweight container that's J2EE certified.

    I think its fair to turn the tables and ask you a similar question... Why is allowing vendors to choose when to drop backwards compatibility for old versions of a specification such a bad thing - unless you're an existing vendor with turf to protect? Do you work for a J2EE vendor Randy?
    At this point in the conversation it's looking like you're interested mainly in flailing against EJB and the J2EE specs in general.
    Not at all. All I'm saying is that 3.0 is such a departure from the previous specs that it can and should stand on its own.
    Having backwards compatibility in the spec gives customers a higher comfort level than promises from their current vendor alone. If you don't buy that argument, I guess you're free to develop and market your own application server and see how your customers feel about standards and backward compatibility. :)
    Baloney. I've said it before - customers will hold their vendors accountable for backwards compatibility to specifications, and that's the way it should be.

    And as to your "I guess you're free to write your own" statement, my whole point - which you keep missing - is that I'm in fact NOT free to do so unless the specs are decoupled.
  36. But apparently there's a lot of agreement in the community that EJB has in many ways been a failure or EJB3 wouldn't be such a departure from previous specs.

    I've always been skeptical of the pronouncements that EJB has been a failure mainly because I see so many successful EJB projects in production. I think a fairer measurement would be to measure EJB project failures against project failures in general. My guess is that they would be pretty equal. The fact remains is that even if you have a good specification, the success of a project really depends on the development team and how the project is managed. Hell...there were successful CORBA projects!

    Bill
  37. But apparently there's a lot of agreement in the community that EJB has in many ways been a failure or EJB3 wouldn't be such a departure from previous specs.
    I've always been skeptical of the pronouncements that EJB has been a failure mainly because I see so many successful EJB projects in production. I think a fairer measurement would be to measure EJB project failures against project failures in general.

    Bill, how can you speak like that on the TSS ??? :)))

    Do not you know that if you migrate from EJB 2.1 to Spring/Hibernate/JDO/EJB3, your productivity, performance and scalability automatically double ...

    IMO a migration from EJB 2.1 to EJB 3 will bring:
    - 10% better developer productivity (no JNDILocator)
    - same performance and scalability
    - rich OO domain model (I do not stress my Oracle by that anyway)

    I do not say there is no reason to go from EJB 2.1 to EJB 3, but sayings like "EJB 2.1 is crap and all your problems can be solved by Spring/Hibernate" are IMO silly ...

    Your comments are welcomed ...

    Damian
  38. But apparently there's a lot of agreement in the community that EJB has in many ways been a failure or EJB3 wouldn't be such a departure from previous specs.
    I've always been skeptical of the pronouncements that EJB has been a failure mainly because I see so many successful EJB projects in production. I think a fairer measurement would be to measure EJB project failures against project failures in general.
    Bill, how can you speak like that on the TSS ??? :)))Do not you know that if you migrate from EJB 2.1 to Spring/Hibernate/JDO/EJB3, your productivity, performance and scalability automatically double ...IMO a migration from EJB 2.1 to EJB 3 will bring:- 10% better developer productivity (no JNDILocator)- same performance and scalability- rich OO domain model (I do not stress my Oracle by that anyway)I do not say there is no reason to go from EJB 2.1 to EJB 3, but sayings like "EJB 2.1 is crap and all your problems can be solved by Spring/Hibernate" are IMO silly ...Your comments are welcomed ...Damian

    I wasn't talking about productivity. And I agree with you on that point. I was talking about project failures. I'm saying that project failures happen in spite of EJB, not because of it. Projects fail because the scope is too large, management sucks, or the developers are too incompetent. People ditched CMP not because projects failed, but rather because EJBQL was crippled and there weren't stupid common sense things like dynamic queries.

    Bill
  39. Yes, the POJO spec will be nice, but its already slated to be released as a separate spec. That's not enough. I haven't used EJB persistence since a horrible failure with the 1.1 model, and I've grown increasingly discontent with the rest of the EJB specification over the years;
    Yeah, yeah...we know you think EJB has been a horrible failure, etc. Please tell us exactly why releasing the POJO persistence spec (or whatever name is better) as a separate spec would not be enough. At this point in the conversation it's looking like you're interested mainly in flailing against EJB and the J2EE specs in general.
    Again, I challenge you and anyone else who supports the status quo to provide evidence that customers who want backwards compatibility actually understand the difference (and care) whether its done by the vendor or required in the specification.
    For the same reason that customers like standards in general -- it gives them the flexibility to choose among different, competing implementations, knowing that as long as they write to the specification, their code will continue to run going forward. Having backwards compatibility in the spec gives customers a higher comfort level than promises from their current vendor alone. If you don't buy that argument, I guess you're free to develop and market your own application server and see how your customers feel about standards and backward compatibility. :)Randy


    Just to lay people's cards on the table, from a quick google search Randy is a WebSphere developer. For me, as an application server customer rather than an application server vendor, your comments seem somewhat disingenuous. You've failed to show how separating the 3.0 specification from the 2.1 specification hurts customers. I certainly understand how it could (potentially) hurt IBM, but, sorry, I don't really care because I don't work for IBM.

    There is not a single non-trivial sized J2EE project in production that would think they could drop their application in a different app server without testing and tweaking. J2EE production deployments are about the vendor environment, not so much the spec.

    Spec != Vendor

    The vendor supports the spec, allowing you to code to the spec APIs and have some reasonable chance of being able to port in a non-cost-prohibitive manner (assuming you don't need anything beyond the spec... yeah), but the execution environment becomes more important than the spec when you get to the operations team. Does your ops team care whether you're coding to the JMS 1.0.2 or 1.1 version of the spec, or do they care whether it's MQSeries, Sonic, WebLogic JMS, or ActiveMQ?

    IBM, BEA, Sun, Oracle, etc. won't be able to drop support for EJB 2.1 for a LONG time. Most likely, new companies won't even try to compete with them in this space, they've already won. As long as new entrants are required to include support for EJB 2.1 in their EJB 3 container, you won't see a lot of new entrants to compete there either. Either that, or they'll do just enough to pass the TCK for EJB 2.1 and push out shoddy, non-production-ready EJB 2.1 implementations which are just enough to get by. This will serve to dilute and weaken the EJB 2.1 brand.

    Again,

    Operation Environment == Vendor != Spec

    As a customer, I'm telling you, as a vendor, that what I want is options. For one thing, if I could get your app server without all the old cruft, it would be smaller and faster to start up. If other vendors can more quickly implement EJB 3 then I have more options for an EJB 3 container (good for me, bad for you). If other vendors want to implement 2.1 and I've got code which I need to support on 2.1, then I've got options there too. If not, then some subset of vendors will continue to support it as long as there's money to be made there. COBOL anyone?

    P.S. The way I remember the vote, there were like 50 people there, and about 30 voted. The only dissenting vote I remember was Hani.
  40. I had asked the author whether he wanted to deprecate / throw away just the 2.1 EntityBean spec, or everything else too including stateless/stateful session beans. His reply was:
    What I'm advocating is the entire spec to be forked, including entity, message-driven, stateful, and stateless session beans.

    The goal is to be able to have a lightweight container that's fully EJB compliant without having to pull forward anything form the old model that's been clearly discredited. This includes not just the entity layer (which few people used anyway) but also the old lifecycle and deployment descriptor management.

    That indicated to me that he wanted to throw away the entire EJB 2.1 spec and fork the new one so it only included the POJO persistence model. So I was asking: Given that the POJO persistence model is already being released as a separate spec, why wouldn't that give him what he is asking for?

    By the way, I've never made it a secret that I work for IBM. My questions so far have been purely to nail down what the author is asking for. IBM will continue to do what customers want and what makes money for IBM. As with all vendors, if what's delivered is not the former, the latter won't happen.

    My question was essentially: If you get rid of stateless session beans, stateful session beans, message-driven beans, 1.x entity beans and 2.x entity beans, what's left that's not in the standalone POJO persistence spec?

    From the last couple posts, it seems clearer that whats really being requested is for the EJB3 expert group to deprecate/remove everything that was in the EJB 2.1 spec and release the POJO persistence spec under the name "EJB3", leaving the previous EJB specs to be supported on a vendor-by-vendor basis only. I guess that's up to the expert group, though since most members of the expert group have existing customer bases to support I'd be surprised if they went that way.

    Randy Schnier
    (I work for IBM but certainly don't speak for IBM)
  41. IBM will continue to do what customers want and what makes money for IBM. As with all vendors, if what's delivered is not the former, the latter won't happen.

    That's one way to look at it. Another would be that IBM makes the most painful and least usable application server out there and yet manages to book revenue for it anyway (notice I didn't say they sell it), and will continue to do so no matter how much pain they cause developers.
    My question was essentially: If you get rid of stateless session beans, stateful session beans, message-driven beans, 1.x entity beans and 2.x entity beans, what's left that's not in the standalone POJO persistence spec?From the last couple posts, it seems clearer that whats really being requested is for the EJB3 expert group to deprecate/remove everything that was in the EJB 2.1 spec and release the POJO persistence spec under the name "EJB3", leaving the previous EJB specs to be supported on a vendor-by-vendor basis only. I guess that's up to the expert group, though since most members of the expert group have existing customer bases to support I'd be surprised if they went that way.Randy Schnier(I work for IBM but certainly don't speak for IBM)

    No, that's not what we're asking for. We want EJB3, including the nicer annotation-based metadata for session and message driven beans and excluding the home/remote interface cruft and also, IN ADDITION, the POJO persistence. We want a new entrant to be able to just start with the new spec, the new way of developing EJBs, and not have to support the past IF THEY CHOOSE NOT TO. If that were to happen, I'd start a pool as to how long it would take Spring to put out a release candidate of an EJB3 container....
  42. We want EJB3, including the nicer annotation-based metadata for session and message driven beans and excluding the home/remote interface cruft and also, IN ADDITION, the POJO persistence. We want a new entrant to be able to just start with the new spec, the new way of developing EJBs, and not have to support the past IF THEY CHOOSE NOT TO.
    Thanks for clarifying that. Wish the author had stated that in their initial post.

    Randy
  43. What I'm advocating is the entire spec to be forked, including entity, message-driven, stateful, and stateless session beans.

    The goal is to be able to have a lightweight container that's fully EJB compliant without having to pull forward anything form the old model that's been clearly discredited. This includes not just the entity layer (which few people used anyway) but also the old lifecycle and deployment descriptor management.
    That indicated to me that he wanted to throw away the entire EJB 2.1 spec and fork the new one so it only included the POJO persistence model.
    I don't see how what I said in that post or the initial post ever indicated all I cared about was the POJO persistence model. In fact, I said "I'm not all that interested in the POJO spec in the first place.".
    Thanks for clarifying that. Wish the author had stated that in their initial post.
    Again, I'm not sure what part of my initial post led you to believe that all I cared about was POJO persistence. But I really don't care at this point; I'm glad you finally get it. Thanks Jason for putting it in simple and impossible to misread terms.
  44. In the initial post, the author said:
    If the spec committee is adamant that old versions be supported, at a minimum they could cut the cord from EJB 3.0 to EJB 2.1, let EJB 3.0 be a nice thin specification (shaving off hundreds of pages from the spec, probably) and allow the J2EE specification to require EJB 2.1 and EJB 3.0 both. That way a lightweight container could fully implement EJB 3.0 even if it doesn't achieve full J2EE certification.

    If you replace "EJB 3.0" with "lightweight POJO persistence spec" in the above paragraph it becomes:

    If the spec committee is adamant that old versions be supported, at a minimum they could cut the cord from <the lightweight POJO persistence spec> to EJB 2.1, let <the lightweight POJO persistence spec> be a nice thin specification (shaving off hundreds of pages from the spec, probably) and allow the J2EE specification to require EJB 2.1 and <the lightweight POJO persistence spec> both. That way a lightweight container could fully implement <the lightweight POJO persistence spec> even if it doesn't achieve full J2EE certification.

    And that's in fact what the open letter from Sun laid out. The lightweight POJO persistence spec is a nice, thin specification, and a vendor can fully implement it even if they don't achieve full J2EE certification. Hence, my questions.

    Randy
  45. but also the old lifecycle and deployment descriptor management.

    I think the old lifecycle model has been fixed as you pull it in now on an as-needed basis, or, what do you mean by this??

    Bill
  46. but also the old lifecycle and deployment descriptor management.
    I think the old lifecycle model has been fixed as you pull it in now on an as-needed basis, or, what do you mean by this??Bill
    In the new EJB 3.0 the lifecycle callbacks and everything have been changed, along with the deployment descriptor model as well. Both are markedly improved (and appear for the first time to be usable without a lot of tools around them). So I'm saying keep the good new stuff (stateless session beans, stateful session beans, message beans, and new pojo persistence) in its own spec unencumbered by the previous versions of all those models.
  47. A Bean by any other name: EPB[ Go to top ]

    EJB was a good spec for its time: early Java dynasty. But like all things, much has been learned since the beginning.

    I agree with the author that carrying the weight of EJB 1.0 forward forever is not a good thing. However, having a spec called EJB 3.0 that is not reverse compatible to EJB 2.0 is potentially confusing.

    Coupling this issue with the JDO / EJB convergence proposals, why not just quietly freeze both JDO and EJB, and instead begin a converged modern solution under a different name, say EPB: Enterprise Persistent Beans (or whatever).

    In this manner, commercial vendors can support both EJB and EPB keeping their existing customer happy, opening a clean pathway into the future, and have good clarity of their product offering.

    Steve Punte
    www.jxreports.com
  48. A Bean by any other name: EPB[ Go to top ]

    Steve, I think this is a great idea. I don't personally think that purging the EJB spec as it stands today is a good idea.
  49. A Bean by any other name: EPB[ Go to top ]

    Again, I'll say I'm not advocating not purging anything, I'm advocating a fork. The old stuff should live out there and be vendor-supported. I will pesonally rely on that for a period of time.

    To anybody that supports continuing to REQUIRE backwards compatibility from ALL certified vendors, I ask this: when it it appropriate to drop support for old versions? Clearly we don't want to wait for 9.0 to drop the 1.0 model, so when? If the specification team removes support from the 1.0 model from 9.0, does it mean that vendors that still support the 1.0 model are no longer compliant?

    I personally don't agree with the proposal to rename it (there's a huge brand built around EJB already, a simple thing like rebranding it could have a massive impact in the adoption curve) but I understand the sentiment. Decoupling the specification versions is the best way to ensure success.
  50. A Bean by any other name: EPB[ Go to top ]

    I personally don't agree with the proposal to rename it (there's a huge brand built around EJB already, a simple thing like rebranding it could have a massive impact in the adoption curve) but I understand the sentiment. Decoupling the specification versions is the best way to ensure success.

    IF the desired new persistence paradigm of EJB 3.0 is indeed so radically different from earlier EJB, is a rebranding that difficult politically?

    javax.ejb.* for were we've been.

    javax.epb.* for were we're going.

    Most vendors would have both for a long time. This truly allows the new spec to completely refactor and simplify itself.

    But, politics IS everything in this world!

    Steve Punte
    www.jxreports.com
  51. A Bean by any other name: EPB[ Go to top ]

    I personally don't agree with the proposal to rename it (there's a huge brand built around EJB already, a simple thing like rebranding it could have a massive impact in the adoption curve) but I understand the sentiment. Decoupling the specification versions is the best way to ensure success.

    Is that like if Microsoft calls its .NET platform DNA 3.0?
  52. A Bean by any other name: EPB[ Go to top ]

    I personally don't agree with the proposal to rename it (there's a huge brand built around EJB already, a simple thing like rebranding it could have a massive impact in the adoption curve) but I understand the sentiment. Decoupling the specification versions is the best way to ensure success.
    Is that like if Microsoft calls its .NET platform DNA 3.0?


    Actually, .NET was to be called COM+ 2.0 at the beginning.
  53. Renaming EJB to EPB is probably not wise. The last thing we want people to think is that it is all about persistence! :)

    EJB is a lot of things. I would rather support having EJB be basically an umbrella spec (as J2EE is now).

    It would have a persistence spec which would be short:

    "This spec builds on the 'Java Persistence API' and this is how we play nicely with it (e.g. getting transaction managers etc)"

    Of course the 'Java Persistence API' would be a standard API in J2SE which would be transparent persistence (a la JDO).

    Then we could have a security spec, tx spec, blah blah. It would also contain the core programming model that we have.

    Dion
  54. One good thing that will come out of EJB 3.0 that I think will help to alleviate some(not all) of Tim's concerns is that AFAIK, vendors will be allowed to provide EJB 3.0 persistence solutions as standalone products.

    This is *very* good for J2EE. JMS has already shown how a healthy sub-component market can enhance the J2EE platform.

    Bill
  55. One good thing that will come out of EJB 3.0 that I think will help to alleviate some(not all) of Tim's concerns is that AFAIK, vendors will be allowed to provide EJB 3.0 persistence solutions as standalone products.This is *very* good for J2EE.

    Two such products are Hibernate and Toplink.
  56. One good thing that will come out of EJB 3.0 that I think will help to alleviate some(not all) of Tim's concerns is that AFAIK, vendors will be allowed to provide EJB 3.0 persistence solutions as standalone products.This is *very* good for J2EE. JMS has already shown how a healthy sub-component market can enhance the J2EE platform.Bill

    I fully agree regarding the value of standalone EJB3 persistence solutions, analogous to JMS. A major enabler here is standalone certification, and dedicated coverage of standalone use in the spec. I've been asking for this publically since Linda's first EJB3 presentation at TSS (see Hibernate blog, Hibernate forums, and other places).

    However, the initial reaction from the EJB3/Hibernate side of things was less than supportive. Specific points I made in a long email to Gavin and Christian were labeled as "too boring" to bother to reply. JBoss would provide a standalone implementation based on Hibernate anyway, and everything else was none of their interest.

    Only the political power of Sun was able to force a re-focus of EJB3 persistence, getting more expert group members on board and enforcing a standalone EJB3 persistence spec. So much for the original motives and the will to create "a healthy sub-component market that can enhance the J2EE platform".

    Juergen
  57. However, the initial reaction from the EJB3/Hibernate side of things was less than supportive. Specific points I made in a long email to Gavin and Christian were labeled as "too boring" to bother to reply. JBoss would provide a standalone implementation based on Hibernate anyway, and everything else was none of their interest.

    Wrong Juergen, it was not interesting _at that time_. We had much more important things to do and focused on technical issues, not on little details. We knew that it would happen at some point so why bother... Nice spin to label JBoss as evil and non-interested in anything though.
  58. Wrong Juergen, it was not interesting _at that time_. We had much more important things to do and focused on technical issues, not on little details. We knew that it would happen at some point so why bother... Nice spin to label JBoss as evil and non-interested in anything though.

    Nice try to call something as fundamental as factoring out EJB3 persistence into a separate spec (and consequences on the design of the EJB3 EntityManager) as "little details". Good to know that such well-balanced attitudes ruled the EJB3 expert group (at least the original group).

    My main point is that neither Hibernate nor JBoss ever pushed a separate persistence spec, despite many people having asked for that. You always wanted to push the JBoss standalone EJB3 EntityManager, but not a factored-out persistence spec. You certainly can't claim to have had a "healthy sub-component market" in mind.

    IIRC, you even threw me out of the Hibernate forums for repeatedly stating that a standalone JBoss EJB3 EntityManager was not good enough. I always insisted that dedicated design for EJB3 standalone usage was necessary *in the spec*. Such a design shouldn't be an afterthought: It should be kept in mind from the early stages.

    Juergen
  59. However, the initial reaction from the EJB3/Hibernate side of things was less than supportive. Specific points I made in a long email to Gavin and Christian were labeled as "too boring" to bother to reply. JBoss would provide a standalone implementation based on Hibernate anyway, and everything else was none of their interest.Only the political power of Sun was able to force a re-focus of EJB3 persistence, getting more expert group members on board and enforcing a standalone EJB3 persistence spec. So much for the original motives and the will to create "a healthy sub-component market that can enhance the J2EE platform".Juergen

    I never got an email from you, so I have no idea what you're talking about. Besides, why should we (or any EJB vendor for that matter) take any suggestions you make on EJB3 seriously when the premise of your business model is to undermine EJB("J2EE without EJB") and promote your own proprietary product?

    I think the best interest of your community would be to bring Spring's message to a standardization effort like EJB so that other vendors could get in on the act of promoting Spring's message (and thus move the industry in a better direction). If not EJB, then why not the J2EE JSR? I know Rod is an expert there. JBI maybe? Sounds like another possibility for a standard kernel. Then again...maybe you care less about the message and more about revenue?

    Bill
  60. Besides, why should we (or any EJB vendor for that matter) take any suggestions you make on EJB3 seriously when the premise of your business model is to undermine EJB("J2EE without EJB") and promote your own proprietary product?

    Well, in particular after the thorough analysis of EJB <= 2.1 that led to "J2EE without EJB", we should know our stuff, I would argue. Our book laid out how sophisticated J2EE development can happen without EJB <= 2.1; even Linda herself uses arguments that seem to be taken from our book - against her own current production programming model!

    Anyway, at least back last year, JBoss group members pushed the idea of a vendor-specific JBoss standalone EJB3 EntityManager rather than dedicated standalone EJB3 persistence in the spec. So much for proprietary products.

    Back last year, I was mainly interested in the perspective on how to integrate EJB3 persistence into a Spring-based application. (Yes, we were considering that right from the start, without any oh-so-dark motives.) Gavin and Christian essentially killed our motivation to participate in the shaping of flexible EJB3 persistence.
    I think the best interest of your community would be to bring Spring's message to a standardization effort like EJB so that other vendors could get in on the act of promoting Spring's message (and thus move the industry in a better direction).

    Other vendors *do already* promote Spring's message. We have good relations with many vendors in the J2EE space, and even do co-promotions and collaborations from time to time. Why is that the case? Because we integrate with standard J2EE very nicely, running in synergy on today's (and even yesterday's) J2EE servers.

    Our core approach is a consistent programming model that works outside of J2EE as well as on J2EE >= 1.2 (!!). Yes, this includes older servers such as WebSphere 4 or WebLogic 7, but also standalone applications... all with the same service style, fostering reuse across all those environments. I don't see this fit with any current JSR.

    Struts never got "standardized", but it is nevertheless in wide-spread use - because it *integrates* very well with J2EE, rather than formally being part of it. I would apply the same reasoning to Spring: the most important factor is seamless integration with standard J2EE, not living under the J2EE umbrella itself.

    At least, thanks for the compliment that promoting Spring's message moves the industry in a better direction. I certainly believe that too, and so do other vendors who already welcome Spring running on top of their servers (or persistence products etc) and don't reject service requests for such combos.

    Juergen
  61. Anyway, at least back last year, JBoss group members pushed the idea of a vendor-specific JBoss standalone EJB3 EntityManager rather than dedicated standalone EJB3 persistence in the spec. So much for proprietary products.

    Seriously, what the @bleep@ are you talking about? JBoss was never against a standalone EJB 3 implementation. What we've been against is splitting the specification in EJB 3. It already added a month's work for Linda to split out the documents. The EJB 3.0 opponents already complain how slow we are, why should we be slowed down any further by bureaucratic BS red-tape?

    Because we integrate with standard J2EE very nicely, running in synergy on today's (and even yesterday's) J2EE servers.Our core approach is a consistent programming model that works outside of J2EE as well as on J2EE >= 1.2 (!!). Yes, this includes older servers such as WebSphere 4 or WebLogic 7, but also standalone applications...

    If your approach is so synergistic and core to J2EE, then again, why don't you bring such so-called innovation to a standards body? The Hibernate guys are doing it with EJB3. Why not yourselves? Craig "Struts" McClanahan (spelling) did the same with JSF. Maybe its just that if Spring became standardized where anybody could implement it, then you wouldn't have much of a business differentiator now would you?

    Really, I have no desire to bicker with you, but I'm so sick and tired of hearing how JBoss is what's wrong with the world when folks like yourself have the same goals of building a solid business as well as writing great tech.

    Bill
  62. Craig "Struts" McClanahan (spelling) did the same with JSF.

    Ironically, JSF makes Struts obsolete, but EJB3 makes Hibernate "standardized".
  63. Bill
    Besides, why should we (or any EJB vendor for that matter) take any suggestions you make on EJB3 seriously when the premise of your business model is to undermine EJB("J2EE without EJB") and promote your own proprietary product?
    Ah, your usual "debating" style. Who bothers with technical arguments: just brand your oponent as financially motivated. You honestly can't understand that many other people are capable of technically motivated argument, can you?

    As this is not really a technical debate, I'm not very interested, but I will make some points for the record:

    1. My views on the flaws of the EJB model have been consistent since 2001, and were expressed in 2002 in Expert One-on-One J2EE Design and Development. Back then there was no "business model." In fact, as an independent consultant, my most marketable skill was actually EJB, and the critical message in that book actually caused me some problems. If I'd been marketing-driven, I would have written a book to publicize my EJB expertise. I was actually rather naive at the time, and wrote a book that was based on my experience and honest opinions. Fortunately a lot of people liked it.

    2. I and Juergen designed Spring because of our views on J2EE architecture. That's a bit different from having views on J2EE architecture to promote Spring.

    2. I honestly don't believe that EJB 3.0 (at least the session bean side) is a good technology. I don't believe it's of benefit to most Spring users, and I don't believe that the problems can easily be fixed. What am I supposed to do--shut up because people like you will label me as commercially motivated?

    4. I and Juergen have always expressed our honest opinions on TSS and elsewhere. No astroturfing. No subterfuge. Sometimes those opinions are fashionable, sometimes they aren't. But they're real.

    Criticizing technologies--on technical grounds--is often constructive. Why is EJB 3.0 trying to be more lightweight and incorporating some DI and AOP ideas? Because people criticized EJB 2.1 and demonstrated a superior approach...

    Rgds
    Rod
  64. Bill
    Besides, why should we (or any EJB vendor for that matter) take any suggestions you make on EJB3 seriously when the premise of your business model is to undermine EJB("J2EE without EJB") and promote your own proprietary product?
    Ah, your usual "debating" style. Who bothers with technical arguments: just brand your oponent as financially motivated. You honestly can't understand that many other people are capable of technically motivated argument

    Well, I think you need to talk to Juergen then as he was the one who accused us of non-technical motivations. If you do not like the same kind of speculation thrown at yourself, then stop with the pot-shots at us.
    If I'd been marketing-driven, I would have written a book to publicize my EJB expertise.

    I hear the violins in the background...
    What am I supposed to do--shut up because people like you will label me as commercially motivated?

    No, of course not. Being labeled as commercially motivated never stopped me from voicing my opinion.

    Bill
  65. Well, I think you need to talk to Juergen then as he was the one who accused us of non-technical motivations. If you do not like the same kind of speculation thrown at yourself, then stop with the pot-shots at us.

    Well, it's not exactly about non-technical motivations in general. You're just bending the impression you give, taking the past 10 months into account: a healthy sub-component market was not what you originally intended. This is not a JBoss-only thing of course, rather an EJB3 expert group thing. But you did play your part in locking JDO vendors out until you were politically forced to extend the expert group accordingly.

    Admittedly, "you" does not mean you personally, Bill. I'm not guessing about your personal motivations, and not implying that you *as a person* give a different impression now. JBoss Group as a company does, though, with Gavin and Christian having played a major role in the initial "Hibernate is EJB3, and standalone usage is an afterthought" focus of the spec. Things are different now, with JDO vendors on board etc, but please don't give the impression that this was a JBoss Group achievement.

    Anyway, I'd really prefer to bury this now; it's not important enough to justify a ongoing discussion. I'm also guilty of a knee-jerk reaction here: I admit that I felt personally offended by the non-reaction from Gavin and Christian last year, in particular by their justification that my EJB3 mail was "too boring". I tend to be pretty unforgiving, which is not necessarily a trait I'm proud of. Again, this hasn't much to do with you personally, Bill.

    Peace,

    Juergen
  66. Besides, why should we (or any EJB vendor for that matter) take any suggestions you make on EJB3 seriously when the premise of your business model is to undermine EJB("J2EE without EJB") and promote your own proprietary product?
    And a further point: the value proposition of Spring is far from purely tied up with providing an alternative to EJB (whatever version). It's simply not true to say that the "premise of our business model" is tied up with "undermining" EJB. (You must concede that we know more about our business model than you do, so are qualified to comment on it.) Not to mention, that as I pointed out in my last post, arguing about other people's business models is a questionable tactic.

    Indeed, to a large extent Juergen and my personal views on EJB (whatever version) are just that, and do not dictate an ideological bent to Spring as a whole. We have many Spring users using EJB (obviously 2.1 and earlier at this point): we support them doing that and provide services for them. E.g. the Spring services for accessing remote or local EJBs make EJB 2.x programming very much easier.

    There are also some EJB services that we believe remain valuable and recommend. (See J2EE without EJB: the arguments are detailed and not all black and white.

    Spring also provides a wide range of services that EJB 3.0 does not address. We expect that for users who choose to use EJB 3.0, many of those services will be valuable. As Juergen has pointed out, we will ensure that Spring works in an EJB 3.0 context. We will integrate JSR-220 persistence with Spring's data access abstraction. (Sooner rather than later.) We will continue to offer services for implementing and accessing EJBs, EJB 2.x and EJB 3.x and beyond.

    In short, the whole "Spring vs EJB 3.0" thing is a gross over-simplification.

    Rgds
    Rod
  67. http://chris-richardson.blog-city.com/read/1105675.htm

    It says: "EJB 3 still has no support for maps or collections".

    So in tradition of JCP, I want us all to start saying:
       "Yeah, but wait till next version".
    We need to say that more.
    .V
  68. Yes Yes Yes ....

    There should be a brand new EJB 3.0 spec with no baggage, and a EJB 2.1 spec as it is today - with no ties between the two whatsoever. Let the vendors cater to either EJB 3 or EJB 2 or both as they see fit - Spring cleaning as it were (pun).

    On a side note:
    Would I have to create my whole object model with EJBs to use IoC ? EJBs may have become POJOs but they would carry the same heavy handling (and more) behind the scenes I would presume. I would also be a little nervous littering my whole object model with EJBs given the number of revisions they have gone through.

    Sony
  69. What else in J2EE 5.0? Is J2EE 5.0 all about EJB3?