It's all very interesting, looking in from the outside, and there's lots of entertaining name-calling. Most of what I saw was in a thread on theserverside.com, but alas that thread seems to have expired or been purged while I was off sick.

Anyway, I think things will get interesting in that world. I don't know why Oracle and Hibernate chose to go with EJB. I know that there were some tensions with the JDO approach, but tensions doesn't begin to describe the problems with EJB. On the other hand, EJB's persistence has by now failed spectacularly enough that the committee seems willing to admit the previous two approaches were a bad idea and do a complete rewrite listening to someone who knows something. So perhaps they'll come out with something reasonable (but of course, also backward compatible with the previous two). Given my expriences with that group, I'm doubtful. Fortunately, it doesn't really affect me one way or the other.

The other day I heard about Microsoft's technology associated with Longhorn for mapping. Today there's a join IBM-BEA spec called Service Data Objects that talks about mapping not only to relational sources, but also to XML. IBM page here .

Again, I only glanced at it, but it seems rather more limited, and more XML-oriented than relational-oriented. But it certainly seems like the need for this sort of technology is becoming increasingly mainstream. Maybe we'll start seeing the same sort of Microsoft/Java one-upmanship in features that we've seen in other areas.

OK, Jim's mentioned me in his blog, so I guess I'd better start making some real posts.

An interesting reference that I found via JDO sources. In amongst the kitchen sinks, Longhorn apparently includes some object-relational mapping technology, under the name ObjectSpaces. Unfortunately links into the middle of the site don't seem to work, so you'll have to go to the root and search for ObjectSpaces from there.

There are a lot of people with a lot of very bad ideas about how to approach this kind of problem space, so what I found impressive was that nothing in the (admittedly skimpy, and only skimmed) documentation here leaped out at me as a problem. They seemed to be doing what I'd consider all the basic things. They invented their own string-based mini-query language, but in a non-reflective system that's a little more plausible.

One thing that's a little peculiar is that it seems to be using an equivalent of TOPLink/Java's ValueHolder. We put those in because you couldn't do doesNotUnderstand: proxies in Java, so the cheap solution is to make the layer of indirection in between more visible to the program (it's particularly visible in a statically typed world). Given that this is Microsoft doing it, and they own the CLR, you'd think they could have got some kind of a read barrier in. But apparently not.