EJB 3.0 Persistence: A question of when rather than if
We're starting to get some questions about adding support for new EJB 3.0 Persistence specification. The response is yes, of course we're going to support the new specification. Without doubt, when the specification is approved, it will be a very big event in the Java community. The specification is expected to be finalized in the first quarter of 2006.
So the next next question is: when should the EJB 3.0 Persistence feature be added to FireStorm/DAO?
For CodeFutures, its a question of appropriate timing. Do we go ahead with implementing the current draft of the specification when it will probably change (and improve) over the next few months?
What added benefit is there in providing an early implementation of the specification?
There's already other Java product vendors building technology previews. Oracle, for example, is doing excellent work (but seems to be suggesting that developers use the technology previews of an incomplete specification in real projects?).
So the CodeFutures plan is to start implementing the specification once it is solidified. Then release a GA product based on the specification after it is approved by the JCP.
Will CodeFutures be recommending using EJB 3.0 Persistence in real projects? That remains to be determined.
The issue is that it's a new specification based on input from multiple, divergent sources where compromises must be made. It's very rare to get all the details right in the first version of a specification. In fact, it would possibly be a unique achievement.
So CodeFutures may end up recommending that customers developing important enterprise applications should wait for EJB 3.1 Persistence.
Iif you've got spare time, certainly experiment with the EJB 3.0 previews.
CodeFutures would appreciate any comments, good, bad, and ugly, you have on EJB 3.0 Persistence.
In the meantime, we're looking at Service Data Objects as the next generation for Java persistence.
PJ Murray
CodeFutures Software