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.

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…

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