[Opensource] JDO resources

[Michael Rimov]

At 02:08 PM 1/6/2003 +0100, you wrote:
>Another opensource JDO implementation is XORM (http://xorm.org).
>The introduction I found on their web site :
>
>XORM uses the API described by the Java Data Objects (JDO) specification
>(JSR 12) and implements many of the interfaces specified by JDO. In contrast
>to most JDO implementations, XORM does not require you to run a class-file
>enhancer before deploying your persistence-capable classes. Instead, XORM
>allows you to specify persistence-capable classes using abstract classes or
>interfaces; bean-style get()/set() methods are enhanced at runtime to be
>managed for persistence.

Thanks all for the links.  Between your links and the new JDO book on the 
Serverside, I've been able to get some decent information.

What I like:
         -Good clean API.
         -At least it has a JSR support
         -The fact that it can make any object persistent... this way is 
very cool... and ironically something JBoss 4 is planning on doing too.
         -Binary compatibility between implementations

What I don't like:
         -Security [or lack thereof]:  I don't think there should be an API 
like this without a central focus on security attributes, and I don't see 
this so far in my explorations (correct me if I'm wrong!).  DataObjects are 
going to have Security as their core, maintenance of at least the current 
level of user /table security is of high importance.  Yes, we could always 
wrap things, but to be honest, I believe the security should not be 
separated from persistence.

         -Byte code enhancers.  I fully understand why they do this.  But 
frankly, adding yet ANOTHER deployment step is not something that I look 
forward to.  If the Java Language ends up going the JDO route, obviously, 
this will no longer be an issue.

         -Fine tweaking.  One of the things that Expresso has the 
capability of, and the future data objects will retain that capability is 
the ability to fine-tune your data objects for the underlying data 
store.  For example, JDBCObjects will have some SQL specific methods, and 
folks can always get the underlying sql connection for their own 
high-performance code.  I don't see this capability with JDO. [Although in 
some ways this is a +1 for them because it kept the API cleaner]

So my thoughts?  At this time, I don't think we're ready to switch 
completely over to JDO, I think Expresso has a future with the upcoming 
data objects.  However, I believe we could provide an interface layer to 
allow for quick use of JDO objects from within Expresso.  [We'd just wrap a 
JDO object with a DataObject interface, and have full editability with 
DBMaint, etc]

Now, of course, I'm not interested in starting a war over whether we should 
or we shouldn't.  As I mentioned earlier, since I'm working to separate 
things in Expresso in such a way so as to allow easier persistence engine 
pluggability, so you could develop your Expresso-based apps with JDO if you 
so wish.  However, I don't think at this time it would be wise to jump on 
the JDO bandwagon as the de facto Expresso persistence standard.

Hope this clarifies things, and of course, comments are welcome!

                                                 -Mike