I was just sitting in a talk on ObjectSpaces (Microsofts Java Data Objects). It was interesting to get to see it, and to listen to Luca, the very Italian Program Manager. He was great :)
ObjectSpaces really does look similar to JDO. And it should, it is trying to be transparent persistence.
There were a few interesting pieces of information:
- Many Files: ObjectSpaces consists of 3 XML configuration files.
- OSD: Represent your Object model
- RSD: Represent your DB model
- MSD: Represent the mapping between the two models
. This is interesting to see, especially due to the talks on ubermapping file / seperate files in the JDO expert group. ObjectSpaces has the advantage in that they are the one vendor, so they don’t have to worry about vendor extensions!
- OPath: The ObjectSpaces team originally were using XPath as their query language (their JDO-QL). They had an interesting story in that they showed some queries to their early access partners, and they didn’t like it. “Noone will be able to grok this type of query. Business developers don’t get XPath yet”. They went back, changed the parser to understand a ‘.’ instead of a ‘/’, and the same partners loved it :) So, OPath was born, and it has diverged more from XPath as they realised that a language to query an XML heirachy doesn’t map exactly to the needs of an object graph.
- ObjectSpaces, MDF, WinFS: There can be only one. These three teams have gotten together, as there was a lot of overlap between them. This is the reason that ObjectSpaces won’t be shipped until Longhorn. You could hear the pain in Luca’s voice. He wants it out there… it has been so long.
- Reflection / Bytecode: It sounded like ObjectSpaces is all about reflection. They don’t do any of the cool things that the JDO world can do via bytecode. One painful thing that I saw was that you had to change your “transparent” code from an ArrayList to an ObjectList (part of ObjectSpaces), to get lazy-loading to work. I prefer leaving my source code the same, and having someone else munge it to get it to work.
- Supporting any query: One feature which seemed really cool was the way that they can support you running almost any query (as long as the results have enough info for them to map to an object). Instead of having to use a new type of SQL that uses objects, or forcing a subset of SQL etc… they let you get your DataReader as you normally would in ADO.NET. Then, you simply wrap that reader and you get back to the object world:
DbObjectReader dbr = new DbObjectReader(sqlReader, typeof(Person), ..)
I wonder if we could learn from this in JDO.
A great talk, and very interesting to hear.