AOP Kata: Reusable Aspects JBoss.com May Fool?
May 07

EJB 3.0: Backwards compatibility optional?

EJB, Java, Tech Add comments

Linda DeMichiel was asked if EJB 3.0 would have to be backwards compatible. She immediately said yes.

What would it mean if the backwards compatibility was made “optional”?

  • Containers like Spring could support EJB 3 (they are not going to put in support for EJB 2.1 and below!!!)
  • Other projects could ramp up to support the more lightweight EJB 3 model
  • Other vendors could make a choice on whether they want to support a backwards compatible version. They could even offer two versions!

Would the world be so bad if this was an option? Users would have a choice. If the backwards compatibility means a lot to them, they can choice a vendor which has the optional “Supports 2.1″ checkbox.

The programming model is changing so much, that I think it would be fair to not burden EJB vendors with The Old Ways.

What are the reasons to mandate backwards compatibility?

  • Politics: Current EJB vendors have already implemented it, and can use this as an advantage. It keeps the likes of Spring out of the game.
  • The usual reasons why we like backwards compatibility

Personally, I wish they made it optional, and we could break out on the new road with EJB 3.

4 Responses to “EJB 3.0: Backwards compatibility optional?”

  1. Corby Page Says:

    Dear Dion,

    Please stop being so selfish. Yes, making backward compatibility optional would be beneficial to hundreds of thousands of developers that have the option of developing to the EJB 3.0 spec. And it would spur innovation when new players could enter the market without having to suppport large amounts of semi-deprecated legacy scaffolding.

    But it would also threaten our market dominance. We have to support our legacy customers who deploy EJB 1.x and EJB 2.x applications, so we feel that everyone else should have to support them, too. You see, Dion, if other players were allowed to create EJB 3.0-only containers, they would start kicking our butt in the marketplace and we would have a lot of trouble landing new customers. So, creating artificial impediments to competition is what we call ‘a level playing field.’ And stifling innovation is good for innovation. Knowledge is ignorance.

    Love,
    IBM and BEA

  2. Experiences (Reloaded) Says:

    Quite right concerns on EJB 3.0!

    While I’m closely tracking the discussions, reviews and talkings on the next generation EJB architechture (and really glad to see the officially acceptance of POJOs and DIs/IOCs by major vendors), I do agree with Dion on the concerns he has. Really why…

  3. Alan Green Says:

    Hi Dion,

    What you are calling ‘political,’ I would label ‘commercial.’

    Many J2EE purchasers pay big money for their container. One of the things they are buying is technical stability. They are counting on Sun’s assurances that the the J2EE platform (a) will continue to be supported, maintained and enhanced in the long term – perhaps decades – (b) won’t lock them in to any particular vendor.

    Allowing a certified J2EE container to be incompatible with EJB1.x and 2.x code would damage J2EE’s corporate credibility. That said, I think the market will allow old-style EJBs to be deprecated, and then made optional over the coming five or six years.

    Personally, I would be happy to use an uncertified, J2EE-like container based on the new EJB3 features. Surely a SourceForge project will appear within 3 seconds of the EJB3 spec’s first draft release :)

    Alan.

  4. Dionisius Says:

    kmcioeaepbu hqwu.

Leave a Reply

Spam is a pain, I am sorry to have to do this to you, but can you answer the question below?

Q: Type in the word 'cricket'