Discussions

News: TSS Java Symposium 18 session reports & survey questions posted

  1. TheServerSide's Java Symposium occured 2 weeks ago and we've posted an indepth conference coverage article including summaries of 18 technical sessions, from AJAX to EJB3 to project automation. We've also included the results of 23 audience survey questions, yielding surprising results such as 80% against backwards compatible EJB, 2.5% prefer Netbeans, and 40% say their in house QA team sucks.

    Read: TheServerSide Java Symposium conference coverage

    Threaded Messages (16)

  2. Video coverage?[ Go to top ]

    Do you guys have a video coverage? Video coverage would have been better.

    - Jay
    Sun Java News, Blogs, Forums and Groups
  3. EJB3 Backward compatility[ Go to top ]

    Does backward compatibility matter to you with EJB3? Speak up!

    Backward Compatibility with EJB 2.x, who cares?

    regards
    Debu Panda
  4. EJB3 Backward compatility[ Go to top ]

    Does backward compatibility matter to you with EJB3? Speak up!

    Obviously backward compatibility is going to be important to some customers, and will be supported by the existing vendors. That's not the issue.

    The question is whether someone should be allowed to create an EJB3-only certified container that does not have to support every single prior version of the specification.

    And the community has overwhelmingly said yes.
  5. EJB3 Backward compatility[ Go to top ]

    Does backward compatibility matter to you with EJB3? Speak up!
    Obviously backward compatibility is going to be important to some customers, and will be supported by the existing vendors. That's not the issue.The question is whether someone should be allowed to create an EJB3-only certified container that does not have to support every single prior version of the specification.And the community has overwhelmingly said yes.

    And the Spec Committee has overwhelmingly said no.
  6. EJB3 Backward compatility[ Go to top ]

    There isn't a law saying you can't make a EJB3 only container. Just don't expect to have it certified. If someone makes one that is better than others, it will succeed, regardless of the "Lords On High".
  7. EJB3 Backward compatility[ Go to top ]

    There isn't a law saying you can't make a EJB3 only container. Just don't expect to have it certified. If someone makes one that is better than others, it will succeed, regardless of the "Lords On High".
  8. EJB3 Backward compatility[ Go to top ]

    To me I don't see why the don't expand the certification model and make everyone happy. From what I see most people want to have options here so why not have a EJB 3.0 only certification for containers that don't want to support the bagage of previous versions and an EJB 3.0 backward compatible certification for those that do.

    I would be surprised that if in the long run Weblogic and JBoss do not end up with a configuration setting to turn off backwards compaitibilty for their EJB 3.0 container.

    David
  9. EJB3 Backward compatility[ Go to top ]

    To me I don't see why the don't expand the certification model and make everyone happy. From what I see most people want to have options here so why not have a EJB 3.0 only certification for containers that don't want to support the bagage of previous versions and an EJB 3.0 backward compatible certification for those that do.I would be surprised that if in the long run Weblogic and JBoss do not end up with a configuration setting to turn off backwards compaitibilty for their EJB 3.0 container.David

    +1
  10. EJB3 Backward compatility[ Go to top ]

    There isn't a law saying you can't make a EJB3 only container. Just don't expect to have it certified. If someone makes one that is better than others, it will succeed, regardless of the "Lords On High".

    What is an "EJB3-only" container when backwards compatibility is a requirement of the EJB3 spec?

    The value of a specification is in defining a common standard between implementations. If there is a clear subset of the new spec that is of value independent of the rest, why not define separate from the rest? Vendors could certify that they support the new EJB model defined by this lighter spec, and that would have a clear and verifiable meaning beyond the wink and handshake you would get if "EJB3-only" is not clearly defined. Call it "EJB3 light" if you like. Vendors can then declare which standards they support, and I can choose the product that meets my needs. If I need EJB2 and am willing to pay for it, I am sure some vendors will continue to support it. If I don't, why require the baggage?

    Splitting EJB3 from its predecessors in no way requires that vendors drop support within their products. It simply lowers the barrier to entry in the EJB3 space and makes the very concept of EJB3-only containers that you mention a clearly definable and verifiable thing.
  11. EJB3 Backward compatility[ Go to top ]

    And the Spec Committee has overwhelmingly said no.

    The poll at TSS was actually the first time that a popular result showed so many people in favour of doing this. The Spec Committee has discussed this at length and has been polling people throughout the cycle. We would very much like to not require support for older versions since it would allow even more vendors to provide products, which is definitely a Good Thing for the spec.

    If we came out and said this, though, there would be consequences:

    - The migration story for existing applications would be worse, interop could be non-exsistent, and the new vendors would not even have a chance at any of the existing EJB users
    - The spec would get cricized (as it already has by many) saying that it is taking a new road and has no right to leave existing customers with no support on an old and outdated spec
    - The J2EE platform would be judged harshly as not being evolution-friendly and including forward development paths as part of the next gen specs

    In some ways it is the rock-and-hard-place problem where the spec gets flak either for changing the model and not providing a migration path, or providing one and requiring new vendors to support previous technology.

    Note that to most existing vendors it makes no difference to us whether the spec actually requires it or not. Oracle will certainly support it because we have lots of customers that use it and part of our planned stratgy is to offer them a smooth migration path. If it isn't in the spec then it is just value-add that we have to offer. The bigger issue, though, is whether this is a responsible thing to do.

    In the end if enough of the community and the J2EE platform stewards think it is a good idea then it will happen. We need to think of the overall platform, though, not just a new app that does not want to catch glimpses of previous baggage under the tarps.

    -Mike
  12. The real issue[ Go to top ]

    The problem is that I think people are forgetting how specifications work, and what the actual advantages of a specifications are over some random open source project.

    A specification is a contract. For some customers, one of the biggest selling points of j2ee is that it's backed by specifications, specifications that on the whole, won't be pulled out from under them.

    Should it be possible to have standalone implementations? Sure, it'd be good if they were clearly labelled so, and still had some kind of blessing from Sun. Perhaps they could be called JSR-220 compliant, instead of EJB3!

    The problem with asking the tss crowd is that it's a vocal obnoxious majority where lone contractors run rampant. These guys love to have new toys for every gig, just to keep things interesting. These guys never have to maintain old applications, so quite rightfully, why on earth would backward compatibility matter to them, beyond it being a minor advantage in terms of marketing their chosen technologies?

    I hope the EJB3 group is bright enough (well, they are actually, having met a bunch of them) to realise that the specification should not be born of mob rule. Keep comments from TSS type people in perspective!

    Another factor that is often ignored is that for better or worse, there's an absolutely enormous market of ejb out there. What should these people do? I hardly think that 'screw em, they're too dumb anyway since they chose ejb' is quite the message that Sun would want to put out. TSS types might want to sneer and dismiss those people, but come on, even you guys are bright enough to know that *something* must be done with them.

    EJB3 will attract a lot of new users, that's great and will really give the platform a boost and remove much of the stigma surrounding j2ee (since many other API's are becoming a lot more user-friendly, albeit without the spotlight and glamour of ejb). However, lets not forget that right now, the j2ee market is a huge behemoth where pretty much all the serious money is tied up. While you can earn the admiration and oohing and aahing from the other kids in the playground by denouncing these big guys, that sort of bravado won't do much to make sure that the food on the table is plenty and bountiful.
  13. The real issue[ Go to top ]

    Oh come on Hani. This is disingenuous and intellectually bankrupt and you know it.
    The problem is that I think people are forgetting how specifications work, and what the actual advantages of a specifications are over some random open source project.A specification is a contract.

    Agreed, and J2EE 1.4 is ALREADY a specification and contract. What's wrong with WebLogic and OracleAS being J2EE 1.5 AND J2EE 1.4 certified?
    For some customers, one of the biggest selling points of j2ee is that it's backed by specifications, specifications that on the whole, won't be pulled out from under them.

    Did someone mention de-certifying the J2EE 1.4 specification? Are we talking about not allowing people to code to that spec and not allowing vendors to support it, even in new products?
    Should it be possible to have standalone implementations? Sure, it'd be good if they were clearly labelled so, and still had some kind of blessing from Sun. Perhaps they could be called JSR-220 compliant, instead of EJB3!The problem with asking the tss crowd is that it's a vocal obnoxious majority where lone contractors run rampant. These guys love to have new toys for every gig, just to keep things interesting. These guys never have to maintain old applications, so quite rightfully, why on earth would backward compatibility matter to them, beyond it being a minor advantage in terms of marketing their chosen technologies?I hope the EJB3 group is bright enough (well, they are actually, having met a bunch of them) to realise that the specification should not be born of mob rule. Keep comments from TSS type people in perspective!Another factor that is often ignored is that for better or worse, there's an absolutely enormous market of ejb out there.

    You're making my case here. There's a huge market. Do huge markets usually go ignored by vendors? If you know of any huge markets going ignored by vendors please drop me an email (offline, I don't need every independent contractor on here with nothing else to do to compete with me).
     What should these people do? I hardly think that 'screw em, they're too dumb anyway since they chose ejb' is quite the message that Sun would want to put out. TSS types might want to sneer and dismiss those people, but come on, even you guys are bright enough to know that *something* must be done with them.

    Are you really dependent on J2EE, or are you dependent on your vendor? You develop a product, so you may have gone through the pain of making sure it runs on more than one appserver (I've been through that pain), but people who are just writing applications for internal use are most likely NOT doing this, they're using the corporate standard app server vendor. Whether or not EJB 2.1 spec compliance is required by the EJB 3 spec, they'll really only care if it still works in the new version from their vendor, and their vendor will have a huge incentive to make sure it DOES work, or the customers will have to make a decision on porting to EJB3, where they may or may not choose the same vendor, or porting to a different EJB 2.1 implementation.
    EJB3 will attract a lot of new users, that's great and will really give the platform a boost and remove much of the stigma surrounding j2ee (since many other API's are becoming a lot more user-friendly, albeit without the spotlight and glamour of ejb). However, lets not forget that right now, the j2ee market is a huge behemoth where pretty much all the serious money is tied up. While you can earn the admiration and oohing and aahing from the other kids in the playground by denouncing these big guys, that sort of bravado won't do much to make sure that the food on the table is plenty and bountiful.

    That money will continue to flow. J2EE doesn't require COBOL runtime bindings either, and yet there manages to be a lot of COBOL code running out there...
  14. The real issue[ Go to top ]

    Oh come on Hani. This is disingenuous and intellectually bankrupt and you know it.

    Oh come on, that'd be like me saying that you're only bitter about EJBs and J2EE because you get hired for that stuff (sure, you spend all your time migrating away from it, but it's the j2ee knowledge that gets you in).
  15. The real issue[ Go to top ]

    I share Hani's viewpoint. For the large customers who really pay the bills and fund the continued development of the J2EE platform through their purchases of J2EE-compliant products, they make major long-term investments in whatever application platform they choose (we're talking about the level of J2EE vs. .NET for the customer's next 10 years). A major reason they went with J2EE in the first place was the "contract" that these specs make a serious commitment to backward compatibility -- that their investment in this platform will be protected over time by the specification itself, not the whims of a particular vendor.

    On a previous thread someone implied I was taking this view because I happen to work for a large app server vendor (IBM). Yes, I happen to work for IBM but my views come more from the types of customers I typically work with (large), the amount of money they invest in their application platform (large) and the importance they place on the chosen platform's long-term stability and incremental upward compatibility (very large). They are making a long-term contract with the application platform they choose, not just with the vendor they choose. If all they cared about was the promises of the particular vendor, they could have gone with a single-vendor platform instead of choosing a standardized multi-vendor platform.

    I understand the arguments of those who want a separate spec (still standardized and multi-vendor) that just covers the new EJB3 model without requiring support for 2.1 and prior models. However, when you go to sell that to a customer and try to convince them to invest in this new "platform", they will assuredly want to know how confident they can be that this new platform will support, for many years, the programming model you're asking them to commit to. Will this platform drop its support for the current model when the next new thing comes along, leaving them with effectively a single-vendor contract again? If there's no long-term commitment that the platform will support the current programming model even when new variants to the programming model come along, the attractiveness of this platform is really no greater than a single-vendor platform.

    Randy Schnier
    I work for IBM but opinions are my own, not necessarily IBM's.
  16. EJB3 Backward compatility[ Go to top ]

    Does backward compatibility matter to you with EJB3? Speak up!
    Obviously backward compatibility is going to be important to some customers, and will be supported by the existing vendors. That's not the issue.The question is whether someone should be allowed to create an EJB3-only certified container that does not have to support every single prior version of the specification.And the community has overwhelmingly said yes.

    My feeling is that anything that brings more vendors to EJB3/J2EE5 will only make the specification stronger.
  17. EJB3 Backward compatility[ Go to top ]

    Does backward compatibility matter to you with EJB3? Speak up! Backward Compatibility with EJB 2.x, who cares? regardsDebu Panda

    No, because anything below 3.0 is garbage and I wouldn't
    waste my time or my company's time developing with it
    given the choice.