This week's book giveaway is in the OCPJP forum. We're giving away four copies of OCA/OCP Java SE 7 Programmer I & II Study Guide and have Kathy Sierra & Bert Bates on-line! See this thread for details.
I've been silently following how JDO vendors have announced implementations during the past year(s) but haven't really had the time/will to try JDO for real. Assuming I was to test JDO on a small personal project (a classical web-based cd/dvd/book library program), which product would you suggest? It has to be free for at least non-commercial use, but preferrably for commercial use as well as I wouldn't want to have to learn two products' differing precompilers and other supporting tools. I know of TJDO (open source) but I've also heard it's not "quite there yet" (can't remember the exact reasoning).
Just for starters, can we define what JDO is? E.g., not what its acronym stands for, but rather what "is it?" What does it do? I'm not familiar with it yet but am curious to know. Best Regards, John Dove
JDO - Java Data Objects Defines the Persistence Interfacing for interacting with the datastore. The datastore appears to be able to be: 1. a filestore (serialized objects) 2. a relational database Whatever class/object instance you want to persist only has to supply an empty constructor. After your class has been compiled, you then run the "enhancer" which creates modified byte code that is actually used by your application. The modified byte code contains the necessary hooks for the specific implementation you are using. Hence the question about which implementation to use. I think it has been hinted at that whatever commercial vendor it is their implementation will work best for their product, much like WebSphere is optimized for DB2 as opposed to Oracle. Not that you can't use WebSphere with Oracle. You can read Chapter 1 of Java Data Objects at the O'Reilly site. http://www.oreilly.com/catalog/jvadtaobj/ Cheers, Mike
All enhancers are required to support standard reference enhancement, which is binary compatible across all JDO implementations. Vendors can add their own additional enhancements, but these should not be visible to other JDO implementations. So the bytecode enhancements are not considered vendor-specific. This has already been covered elsewhere on Java Ranch today.
Can JDO be used for LDAP Directory stores as well. ie. Does this api/vendor impl support LDAP Directory stores, or is JDO strictly for relational data stores.. Rama
Rama Raghavan<br />SCJP2<br />SCWCD
Joined: Jun 14, 2003
JDO implementations are essentially datastore specific. The relational JDO implementations primarily use JDBC to talk to the database, but then they also have database specific logic to handle variations in SQL DDL and DML. A JDO implementation for an object database would use the underlying object database calls. Using JDO insulates you from whether you are using an object, relational, or any other form of datastore. But to use JDO with a particular kind of datastore, like an LDAP datastore in your case, it all depends on whether someone has implemented JDO for that datastore. Someone at JavaOne told me he was real interested in doing JDO for LDAP, so it may make sense. But I am not aware of anyone that has this implemented already. Over time I suspect you will see more and more different kinds of datastores provide a JDO layer that allows an object-level access to the data. You can imagine for some implementations they would provide you with both the persistent Java classes and their JDO implementation so that they could provide you with an object-level, Java centric view of their information. This would be a specialized JDO implementation that would not allow you to define your own object model, but would use the JDO API and a fixed Java object model as the basis for their interface.