Went to a seminar on EJB3 persistence, courtesy of the BEA UG (not sure how I got onto their email list!). The speaker was Patrick Linskey, co-author of "Bitter EJB".
The EJB3 standard is getting closer to being finalised – they hope to have it done by March or so in order to have the TCK and everything ready for next year's Java One in May.
The EJB3 persistence spec:
- is being developed by an expert group separate to the main EJB3 spec, and will eventually be a separate JSR
- is a pluggable, independent piece of JEE3 (Patrick agreed with me that this gradual breaking-into-pieces of JEE has interesting implications for open source, since it lowers the bar to entry for people to just make one piece)
- is a cut-down version of JDO
- is aimed at ease of use
- can be used via annotations (like everything else in JEE3) or via XML files (XML takes precedence over annotations)
Persistent objects in EJB3 are managed by an EntityManager and replace entity beans altogether. The concept of local/remote interfaces is gone; you always need a local EntityManager which is reached via a factory, just like JDO. Also like JDO, EMs can be used outside of a JEE container which is a boon for unit testing. Another similarity is that EMs can use JTA or explicitly coded transactions.
Compulsory superclasses/interfaces are also out of the window (wow – you can do actual OOP with these classes!) but sadly, they are required to have an explicit identity/version fields. (Patrick told me at the pub afterwards that JDO vendors who make EJB3 persistence modules are likely to relieve their users of this burden by continuing to use enhancement.)
There are attach/detach semantics not unlike JDO2, although detach is implicit at the end of every transaction. I suppose this goes some way to easing the fact that the sophisticated lifecycle of JDO objects, with the invaluable hollow state, has been left out. Fetch groups are also missing.
EJBQL is similar in features to JDO2, and therefore way in advance of EJB2 (quote "EJBQL 2 was half-baked; we've tried to fully bake it"). For example it has named queries. However its syntax is SQL-like, like earlier EJBQL, rather than Java-like like JDO. This is pretty reasonable given the wide understanding of SQL, even though, like in JDO there is nothing in EJB3 persistence to say you must use JDBC underneath; it can be used on top of object DBs, flat XML files or anything else (JDO is apparently used for cellphone/PDA apps). Native SQL is not supported (a Very Good Thing IMO) and neither is getting a JDBC connection from the EM.
EJB3 persistence isn't as bad as I thought it might be, but isn't as good as JDO, and nothing in the talk suggested why Java needs two persistence standards (Patrick didn't address the politics of it at all). But if the likes of Oracle wanted to get people building their proprietary dialect of SQL into Java code, they've clearly failed, which makes the whole thing seem a bit pointless. Nevertheless, EJB3 persistence is the standard which will have the widest industry backing (despite the lack of any good reason) and so will inevitably be important in the future.