What is JDO?

[Payam Fard]

Hi all,
What is JDO? What is its relationship with JDBC?
Any good introduction to JDO would be greatly appreciated.
Thanks,
Payam.

[Gustavo Adolpho Bonesso]

JDO is "Java Data Objects"... You can get more information at:
http://java.sun.com/products/jdo/

[Frank Zheng]

Quoted from Sun: Java Data Objects (JDO) is an API for transparent database access. The programmer can write code in the Java programming language that transparently accesses the underlying data store, without using database-specific code.
Check these sites for more information:
http://java.sun.com/products/jdo/
http://www.jdocentral.com/
http://access1.sun.com/jdo/
[ June 17, 2003: Message edited by: Frank Zheng ]

[Gregg Bolinger]

If JDO is an API, why is there no good implementation of this API from Sun? Maybe I am wrong, but there is no JDO API you can download from Sun and just use. We always have to find some 3rd party implementation of the JDO Specification.

[Thomas Paul]

Greg, why is there no good JDBC implementation from Sun? Why do we always have to go to third parties to download JDBC implementations?
By the way, this caught my eye:
The JDO API is being created under the Java Community Process with Craig Russell of Sun Microsystems as spec lead.

[Lasse Koskela]

Originally posted by Gregg Bolinger:
Maybe I am wrong, but there is no JDO API you can download from Sun and just use.

Here. Though it's probably not "industrial strength"...

[Gregg Bolinger]

So are we saying that Sun is not responsible for good implementations of their own API's? Maybe this is a different discussion all together, and I may start one, but this seems like bad business to me.
M$, curse the word, typically has the best implementations of their own API's. Of course that is in part because they don't allow anyone else to develop without paying out of their ass.
Anyway, didn't mean to highjack. So you can ignor this post.

[Chris Mathews]

Originally posted by Lasse Koskela:

Here. Though it's probably not "industrial strength"...

The real problem with the JDO RI is that it uses a simple file-based datastore as its datasource. This is fine for learning how to use the JDO API but it does no good for those that want to use JDO as a persistance layer to an Oracle or DB2 database. For any non-educational uses one must go to a third-party JDO implementation.
There are a couple OSS implementations of JDO. One is OJB and the other is TJDO. However, they are not ready for primetime yet...

[Thomas Paul]

Originally posted by Gregg Bolinger:
So are we saying that Sun is not responsible for good implementations of their own API's?

Let's see... do we use WebSphere and WebLogic EJB servers or do we use something from Sun? Sun publishes the API and let's the marketplace engineer the best products. That is why Java is vastly superior to .NET. We don't have one company competing for business... we have many competing to make the best products.

[Thomas Paul]

Originally posted by Gregg Bolinger:
M$, curse the word, typically has the best implementations of their own API's.

In fact, they have the only implementation of their APIs. But when they do compete, (OWL vs MFC for example) they always lose.

[Lasse Koskela]

Originally posted by Chris Mathews:
There are a couple OSS implementations of JDO. One is OJB and the other is TJDO. However, they are not ready for primetime yet...

That's just about what I've heard about most JDO products. However, I was under the assumption that OJB is not JDO-compliant. I checked the OJB site at Jakarta and they claim JDO 1.0 compliancy by "combining with JDO RI". Any idea what that means? (trying to avoid delving any deeper into OJB documentation )

[David Jordan]

I don't have any knowledge/experience with OJB.
But since Craig Russell gave a OJB talk last week, he should be able to answer your questions relative to JDO compliance of OJB. My understanding is that they already have a solution that is not JDO compliant, but that they are movings towards JDO compliance.
Craig?

[Craig Russell]

I think you might have heard that most open source JDO implementations are not ready for prime time, but the commercial implementations certainly are.
To understand this story you should consider that most well-designed persistence products consist of at least three distinct layers: the user-visible API, a persistence abstraction, and the database-specific driver.
In many non-JDO products, the user-visible piece is coupled to the persistence abstraction. In JDO, the user-visible piece is standard and the persistence abstraction is where the vendor adds value. In the JDO Reference Implementation, there is a pluggable component called the JDO StoreManager which represents the persistence abstraction. By replacing the StoreManager, a JDO implementation can get all the standard behavior by implementing a smaller piece.
Now, OJB pre-dated JDO, and has a well-defined user interface. The current OJB/JDO project aims to repackage their persistence abstraction to be a StoreManager for JDO. In the future, they might decide to implement the entire stack, but it's certainly easier for a persistence product to simply repackage their persistence abstraction layer to implement the JDO RI StoreManager. The same strategy is being used by JBossDO for their persistence story where CMP cannot be used.
In fact, any of the proprietary persistence products could use this strategy and offer both their own interface as well as the standard JDO interface to users.

Originally posted by Lasse Koskela:

That's just about what I've heard about most JDO products. However, I was under the assumption that OJB is not JDO-compliant. I checked the OJB site at Jakarta and they claim JDO 1.0 compliancy by "combining with JDO RI". Any idea what that means? (trying to avoid delving any deeper into OJB documentation )