JDO and EJB Join Forces, But What Will the Spec Look Like?
There’s already a lot of buzz around the leaked information that the JSR-220 (EJB 3) expert group will now be joined by a number of key JDO people, and will be producing a spec for a persistence API which runs both in an EJB container (as before) and outside (J2SE).
I think having a good, standard, persistence spec which runs both in and out of an EJB container is an incredibly positive thing. The direction of the existing EJB persistence draft, issued this spring, limiting the API to running in an EJB container, never made any sense to me or a number of people.
At the same time, I am left quite curious as to what will actually be produced. Based on the letter, it seems like they will still be working off the existing draft in terms of an starting API. I do hope the JSR group has the time and desire to produce a top notch, usable spec, that includes most or all of the useful features from (the much closer in terms of availability) Hibernate 3 and JDO2. When the existing draft came out I was disappointed that it was in some respects only a weaker version of the existing Hibernate 2. It would be pretty tragic if after another 12-24 months (or however long it will take for the spec to finalize and vendors to ship compliant products), the API is not as good as Hibernate 3 and some of the leading JDO versions (KODO for example now has essentially all JDO2 features) already are now or will be in just a few months.
In any case, you can be sure that Spring will be supporting this API in terms of integration support code, similar to the existing Hibernate, JDO, OJB, and iBatis code, as soon as we have something to work with.


Modified

Gabriel Mihalache says:
Added on September 25th, 2004 at 3:21 pmIt would have been best if you would have said that Spring will support it IF it’s any good. Otherwise, you make it sound that anything midly popular or coming from a JSR will make it, regardless of its quality.
Gavin says:
Added on September 25th, 2004 at 6:40 pm“includes most or all of the useful features”
One of the important things to consider when writing specs is that it must be possible for the market to produce competitive implementations. Which means you have to weigh up the value of a feature and decide if it is *really* of sufficient value to a user, or if it just creates an extra barrier to entry for new implementations. If we just throw everything Hibernate3 has into JSR-220, we will create a market with exactly one implementation: namely Hibernate3. One of our goals is to constrain the complexity of the spec, which means we won’t be shovelling in features that are of marginal usefulness (while keeping open the possibility of adding them in a later revision).
“The direction of the existing EJB persistence draft, issued this spring, limiting the API to running in an EJB container, never made any sense to me or a number of people.”
Um. I’ve been telling you guys for months that EJB3 persistence was *absolutely* appropriate for out of container operation, and that vendors would be providing this. I even blogged about this. But “a number of people” found it convenient to disbelieve me.
This was *incredibly* frustrating (especially since I could not talk about everything I knew was being discussed with respect to this). grrrrrr. Anyway, now that it is official we can move on.
Colin Sampaleanu says:
Added on September 25th, 2004 at 7:10 pmGavin,
Thanks for your comment. I could have expressed myself better than “most or all of the useful features”, as essentially what I meant is what I think you said, those features from Hibernate 2, Hibernate 3 and JDO 2 which don’t exist in the EJB 3 persistence spec from this Spring) and which do add some compelling value. I.e. the main thing I was trying to get across was that I hoped the spec would still move forward so it is relatively compelling to use feature wise (not withstanding some things that don’t make sense to add) compared to the proprietary solutions…
the_mindstorm says:
Added on September 28th, 2004 at 1:24 pmHi Colin!
Last readings revealed me that there is some kind of confusion flying around persistence. Maybe at some point it will be necessary to tell the people that persistence is not orm (nor JDBC only).
./the_mindstorm
[read more…]