His basic premise is that EJB 3 fills the gap of the lightweight containers. Although I think it is a great step forward, I think there are a few areas which worry me:
What are we specifying?
I would personally love the expert group to be able to step back and think about what EJB is all about. Where is the “E”, and what should be spec’d?
In my humble opinion, I think that the EJB spec should be a pretty lean one, that acts like the J2EE spec… in that it offers the programming model + integration hooks into other specs. The other specs are basically out there to define the cross-cutting enterprise services, and could later have AOP info.
The obvious example is persistence. Get a new spec for that if you really can’t stomach talking to JDO people. But get it external, and have it for EVERYONE.
There are also many other examples. Security, worker threads, blah blah.
Backwards compatibility requirements
I understand backwards compatibility is good. However, I think it is OK to make some things optional. Having all of the EJB 2.x and below baggage is painful for some people (e.g. Spring) and keeps them out of the loop. Make it optional, and if you ARE backwards compatible you can get a shiny checkbox. Then, if a company gives a monkeys they can get an implementation that has the shiny star.
In some of the open source projects such as Spring, there is an air of inclusion. What do you want to do for persistence? JDO? Hibernate? iBATIS? We will hook in and help you out with all of them.
You don’t feel that same way with the EJB vendors. The feeling is more like “Oh man, they want to hook us into their damn EJB CMP engine that we can’t bloody swap out as the PersistenceManager STILL isn’t pluggable after all these years”.
Come on guys, let’s play nice. You can still compete on features / QoS / etc.
So, although I am excited about EJB 3…. I want more :)