8. Is there any plan to make Hibernate compliant with the JDO Spec?
No. Hibernate will provide an implementation of the EJB3 EntityManager defined by the JSR-220 specification. Sun has just announced that the scope of JSR-220 will be expanded to cover operation outside the traditional monolithic J2EE container.
Sun's recent announcements regarding JDO and EJB 3.0 have made two things particularly clear:
1. ORM is finally perceived as being of strategic importance to users of the J2EE platform.
2. Hibernate is not EJB 3.0.
Hibernate, Toplink and the major JDO implementation vendors are now working side-by-side to create the unified persistence spec for J2EE. Each of these vendors will issue product releases which "preview" features of the EJB 3.0 persistence api as with each incremental spec release. So if you want to, you will be able to use the EntityManager interface with forthcoming editions of your favourite JDO implementation. Hibernate does not appear to have a substantial advantage here, now that the hype is done.
EJB 3.0 and JDO both target transparent object persistence. However there are some differences worth noting:
JDO will have its public spec published in about four weeks time. We had hoped the final spec would be done before the end of 2004, but that will probably slip into Q1 2005 as we wait for feedback on the public spec.
The EJB spec is expected to produce another "Early Draft" this year.
JDO 2.0 does not have any dependencies on Java 5.0. The expert group has agreed that annotations should not be spec'ed until the community has beter implementation experience of using them. Furthermore we are unlikely ever to facilitate the specification of database-specifics (e.g.table/column names) through annotations, as such metadata has a lifecycle that is not inherently linked to the lifecycle of the source code.
JDO 2.0 is backward compatible with JDO 1.0.1, so I guess we got the fundamentals right from the beginning.
Since neither Hibernate nor Toplink nor your favourite JDO imlpementation can claim to "be" EJB 3.0, the choice of which product to use today is just that - a product choice and no longer an API choice. The semantics of object persistence through JDO or EJB 3.0 are likely to be similar enough for evolution from the JDO API to the EJB 3.0 persistence API to be relatively straight-forward. Pick a product which provides you with a highly efficient and capable persistence environment for use today, from a vendor which is influential in the EJB 3.0 specification effort and will provide (a) previews of the new API for "adreneliene junkies" and (b) a parallel usage migration path to the new API for those who choose to migrate once the standard has been ratified.
Will EJB 3.0 become the dominant API? It's possible, but by no means certain. Only time can tell. And Kodo will support both.
Kind regards, Robin.
VP, Professional Services SolarMetric
Author of <a href="http://www.amazon.com/exec/obidos/ASIN/0321123808/ref=jranch-20" target="_blank" rel="nofollow">Java Data Objects</a>
We still haven't seen an explanation from Gavin as to whether the == object equality operator is reliable for Hibernate, and if not, why not.
Changing the Java language semantics for this seems rather unattractive, and can break many high-performance coding and caching techniques using eg IdentityHashMap.
I thought this kind of overhead (reflection) and changed semantics were what everyone was trying to get away from with EJB, why are we still rehashing these old problems and trying to make them EJB3 compliant.