wood burning stoves 2.0*
The moose likes JDBC and the fly likes JDO Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Databases » JDBC
Bookmark "JDO" Watch "JDO" New topic
Author

JDO

Gregg Bolinger
GenRocket Founder
Ranch Hand

Joined: Jul 11, 2001
Posts: 15299
    
    6

I am needing to find out if there is a way to download JDO without going through some 3rd party commercial Package.
Or are there any Open Source Projects that use the JDO Specification besides Hibernate? I know there is Castor, but it does not adhere to Sun's JDO Specs.
What do these companies use as a Library to implement the JDO specs? Do they write them all from scratch? Is there not something like JDO.JAR somewhere or something like that?
Thanks.


GenRocket - Experts at Building Test Data
Anonymous
Ranch Hand

Joined: Nov 22, 2008
Posts: 18944
you can try OJB from Apache project. It supports the JDO Api plus ODMG and the so called Persistence Broker.
You can find this here. The only additional thing you need is the enhacer of the Sun reference implementation.
Then you can include it into your build tasks.
P.S When i tested it last year it was working fine but the documentation was missing some important stuff.
Olli
Chris Mathews
Ranch Hand

Joined: Jul 18, 2001
Posts: 2712
There is another fairly well known OSS JDO implementation. It is TriActive JDO (TJDO). However, it does have one serious limitation; TJDO does not currently support mapping to a pre-existing schema. That is a big show stopper for many.
Which brings me to my main problem with the JDO 1.0 Specification... it completely ignores O/R mapping! This was what a lot of people (myself included) were looking for when it came to JDO. However, the current specification delegates all O/R mapping details to the JDO implementation.
Therefore, pretty much any JDO work that you do today using a RDBMS will be tied to the JDO implementation. This makes the whole standards-based approach much less attractive.
Personally, I am going to stay with more proven O/R mappers such as Hibernate, OJB, and Castor (if I want OSS) or Cocobase/TopLink (for commercial software). When the JDO specification matures (maybe with the next version) then I will take another look.
BTW, right now OJB JDO is pretty weak.
From the OJB Project Page:
OJB does not provide it's own JDO implementation yet. A full JDO implementation is in the scope of the 2.0 release. For the time being we provide a plugin to the JDO reference implementation called OjbStore.

If you are using OJB today then I would recommend their ODMG API over an RI-based JDO implementation.
[ June 08, 2003: Message edited by: Chris Mathews ]
Gregg Bolinger
GenRocket Founder
Ranch Hand

Joined: Jul 11, 2001
Posts: 15299
    
    6

Thanks for the info guys.
I have been playing around with Hibernate and Castor and have yet to get an simple examples working.
Once again, I am faced with inadequate open source documentation as is always the case. And maybe not so much bad docs, but not enough community support to try and debug my problems (no one to ask for help). I have asked questions on Javaranch but I think everyone here is in a similar situation in that no one really knows for sure what causes what problems.
Hiberbate keeps telling me it needs a user defined datasource when I have the database info setup in the correct xml file. And Castor keeps throwing an IncompatibleClassChangeError.
Oh well, I guess I will keep chugging away. Too bad we don't have more of these kinds of questions enough to warrent their own forums. Questions for these products get lost in the shuffle of "Other Java API's" or the JDBC forum.
Loren Rosen
Ranch Hand

Joined: Feb 12, 2003
Posts: 156
Originally posted by Gregg Bolinger:
Too bad we don't have more of these kinds of questions enough to warrent their own forums. Questions for these products get lost in the shuffle of "Other Java API's" or the JDBC forum.

Maybe we need a "data layer" forum?
Gregg Bolinger
GenRocket Founder
Ranch Hand

Joined: Jul 11, 2001
Posts: 15299
    
    6

Originally posted by Loren Rosen:

Maybe we need a "data layer" forum?

I agree to an extent. However, there really aren't that many questions regarding Data Layers it seems or I wouldn't have a hard time finding information. With that being said, if we had some sort of Data Layer forum maybe there would be more questions asked and answered. Maybe the problem is that no one really knows where to post these kinds of questions.
I might post something about this in the Javaranch forum and see what the powers that be have to say about it.
I can see them probably saying those questions should go in the "Other Open Source Projects" forum until there really is a warrent for a forum of it's own. Another idea I might pitch is to have the JDBC Forum also include Data Layer. So maybe JDBC/Data Layers?
Gregg Bolinger
GenRocket Founder
Ranch Hand

Joined: Jul 11, 2001
Posts: 15299
    
    6

Well, if anyone cares, I finally got a simple Hibernate test to work. They released a final version of their 2.0 just today, and updated a few docs accordingly that helped out a bit.
Anyway, I think we still need a place to ask Data Layer questions. Off to the Javaranch forum I go....
Dirk Schreckmann
Sheriff

Joined: Dec 10, 2001
Posts: 7023
Gregg,
If you get bored, I'd be curious to read some comments you might have about getting a Hibernate example to work.
I haven't explored Hibernate yet. I have played with a few other O/R Mapping/JDO-ish APIs - with mixed results.


[How To Ask Good Questions] [JavaRanch FAQ Wiki] [JavaRanch Radio]
Gregg Bolinger
GenRocket Founder
Ranch Hand

Joined: Jul 11, 2001
Posts: 15299
    
    6

Originally posted by Dirk Schreckmann:
Gregg,
If you get bored, I'd be curious to read some comments you might have about getting a Hibernate example to work.
I haven't explored Hibernate yet. I have played with a few other O/R Mapping/JDO-ish APIs - with mixed results.

IF I get bored? What do you mean if? I am always bored. HA. Anyway, shot you an E-mail.
Dirk Schreckmann
Sheriff

Joined: Dec 10, 2001
Posts: 7023
Just a couple of JDO-related comments from JavaOne
Yesterday, a Sun engineer (I forget who - I'll look it up later, maybe) suggested that Sun currently views JDO as an intermediate layer between JDBC and an entity bean. This is in contrast to what I'd thought Sun originally suggested JDO would do, which was to replace entity beans.
Also, during the Web Services Hands On session today, the demo tutorial they had us build made use of Castor JDO - not a Sun JDO implementation, and not even a Sun-like JDO implementation.
At any rate, these persistence layer topics interest me quite a bit. I'm sure we'll be seeing more conversations on the subject 'round these parts.
[ June 17, 2003: Message edited by: Dirk Schreckmann ]
Gregg Bolinger
GenRocket Founder
Ranch Hand

Joined: Jul 11, 2001
Posts: 15299
    
    6

Originally posted by Dirk Schreckmann:
Also, during the Web Services Hands On session today, the demo tutorial they had us build made use of Castor JDO - not a Sun JDO implementation, and not even a Sun-like JDO implementation.

Now that is VERY interesting because I have seen numerous articles related to Castor's JDO implementation NOT following Sun's JDO Standards. Wow! I want to know more about that.
Here is one such article from ONJava.com.
hmmmmm...
mark evertz
Greenhorn

Joined: Apr 11, 2002
Posts: 22
Actually we are using Castor in a bigger web app. right now and are very much satisfied with its functionality and usability. Moreover there are a lot of tools around generating mapping files etc. We are using it with MySql wich works pretty fine.
That JDO should be used as a standard mechanism for CMP in app.-servers seems to be directly connected to the fact, that e.g. Castor is used in JBoss for exactly these tasks.
We are not using any app-servers.
Castor works more like a JDBC wrapper in our environment giving us a more convenient way to access DBs.
Greetings, Mark
Lasse Koskela
author
Sheriff

Joined: Jan 23, 2002
Posts: 11962
    
    5
Originally posted by mark evertz:
That JDO should be used as a standard mechanism for CMP in app.-servers seems to be directly connected to the fact, that e.g. Castor is used in JBoss for exactly these tasks.

One (probably FAQ) question that pops in mind is "aren't the appserver vendors likely to write hand-optimized JDBC code in order to beat the cr*p out of your-favorite-competitor"?
What would be the main reasons for using JDO implementations, Hibernate, Castor, etc. object-oriented persistence layers in a middleware product?


Author of Test Driven (2007) and Effective Unit Testing (2013) [Blog] [HowToAskQuestionsOnJavaRanch]
John Dunn
slicker
Ranch Hand

Joined: Jan 30, 2003
Posts: 1108
Originally posted by mark evertz:
That JDO should be used as a standard mechanism for CMP in app.-servers seems to be directly connected to the fact, that e.g. Castor is used in JBoss for exactly these tasks.

I originally saw something like this and thought JDO was meant for EJBs/Appservers. Are people really using JDO for straight App->JDBC usage?? If so, is it adding value or just adding a new technology to your app??


"No one appreciates the very special genius of your conversation as the dog does."
Gregg Bolinger
GenRocket Founder
Ranch Hand

Joined: Jul 11, 2001
Posts: 15299
    
    6

Originally posted by John Dunn:

I originally saw something like this and thought JDO was meant for EJBs/Appservers. Are people really using JDO for straight App->JDBC usage?? If so, is it adding value or just adding a new technology to your app??

After using Hibernate for a little while on some simple test apps, I would say it does add value to simple solutions. The value is a more OO design approach when it comes to accessing DB's. Beans are everywhere. Even Paul saw a need for a better DB approach than straight JDBC. That's why Jenny came to be.
David Jordan
Author
Ranch Hand

Joined: Jun 14, 2003
Posts: 66
JDO can be used in an application server or separate from an application server. By the way, JBoss has announced they will be providing their own JDO implementation in Jboss 4.0.
JDO allows you to directly store your Java object models. JDBC does not give you this, it requires you to work with a relational data model. Most people using JDBC never get an object model defined for their persistent data, losing out on the benefits of object-oriented development.
Do you really need entity beans? Entity beans are primarily targetted as objects that can be called remotely. JDO does not assume remotability, it is solely focused on object persistence.
Some have made comments that the OR mapping is not defined in JDO 1.0. This is a planned feature for JDO 2.0. The difference among JDO vendors is that there is a different extension key value in one line of metadata for each class and field in your metadata file. But the Java source remains identical, so you have complete portability of your Java source across all JDO implementations, but you do have a different metadata file. With most products, you can define the OR mapping using a GUI tool where you can associate classes with tables and fields with columns, letting the GUI tool generate the metadata for you. So you don't have to deal with the metadata differences among the different JDO implementations. And this is only an issue if you switch from one JDO vendor to another.
David Jordan
Author
Ranch Hand

Joined: Jun 14, 2003
Posts: 66
One more comment.
Castor, Hibernate, etc., these are all open source, but also proprietary products, supported by a single party. JDO has about 15 commercial implementations now, from companies competing with one another for your business. The JDO application code will be binary compatible across these different JDO implementations. Competition in the JDO space will likely lead to superior solutions.
Bogus user
Greenhorn

Joined: Jun 16, 2003
Posts: 7
Check out http://www.jdocentral.com/ for info on JDO implementations. There are some OSS ones there.
David Jordan
Author
Ranch Hand

Joined: Jun 14, 2003
Posts: 66
Through jdocentral.com you can download many of the JDO implementations for a free eval. They are also not that expensive per developer right now due to the economic slump. Some provide a developer license for $600. This will pay for itself in the first week when you compare using JDO versus using JDBC.
jacob nikom
Greenhorn

Joined: Oct 01, 2001
Posts: 12
This is the message mostly for Craig Russel and David Jordan.
It will be interesting to know when JDO 2.0 is going to be released? What additional functionality is going to be there?
Jacob Nikom
Gregg Bolinger
GenRocket Founder
Ranch Hand

Joined: Jul 11, 2001
Posts: 15299
    
    6

Originally posted by David Jordan:
Through jdocentral.com you can download many of the JDO implementations for a free eval. They are also not that expensive per developer right now due to the economic slump. Some provide a developer license for $600. This will pay for itself in the first week when you compare using JDO versus using JDBC.

What about non-commercial implementations? Like Hibernate? Or is Hibernate not a true JDO implementation?
Craig Russell
Author
Greenhorn

Joined: Jun 16, 2003
Posts: 28
Hi Jacob,
A formal proposal for JDO 2.0 is being worked on by the former JDO expert group. The major objectives are to standardize the O/R mapping so you have more portable code/metadata when using a relational database with JDO.
The working assumption is that JDO 2.0 will be developed to release prior to or concurrent with J2SE 1.5 so we can take advantage of things like generics and metadata.
Craig
Originally posted by jacob nikom:
This is the message mostly for Craig Russell and David Jordan.
It will be interesting to know when JDO 2.0 is going to be released? What additional functionality is going to be there?
Jacob Nikom
Craig Russell
Author
Greenhorn

Joined: Jun 16, 2003
Posts: 28
Hibernate and Castor JDO are not Java Data Objects solutions; they are proprietary.

Originally posted by Gregg Bolinger:

What about non-commercial implementations? Like Hibernate? Or is Hibernate not a true JDO implementation?
Gregg Bolinger
GenRocket Founder
Ranch Hand

Joined: Jul 11, 2001
Posts: 15299
    
    6

Originally posted by Craig Russell:
Hibernate and Castor JDO are not Java Data Objects solutions; they are proprietary.


How are they proprietary? Could you elaborate a little bit?
Craig Russell
Author
Greenhorn

Joined: Jun 16, 2003
Posts: 28
I don't think that "Sun currently views JDO" is quite correct. There are many people at Sun; there are many solutions to persistence offered by Sun; there are as twice as many views as there are solutions.
You really should say "Craig Russell's views on JDO" instead of "Sun's views on JDO".
That said, Craig Russell's view is that to build scalable Web applications, the best use of JDO is in conjunction with JSP pages for display, servlets for business processing (using Struts or JSF when available), and stateless session beans for heavy duty transaction processing. Each of these three has a natural usage pattern with JDO and the solutions are highly portable, scalable, and performant.
In our book we discuss in detail the integration of JDO into web and session containers, and compare JDO with entity beans.
Originally posted by Dirk Schreckmann:
Just a couple of JDO-related comments from JavaOne
Yesterday, I-forget-who (I'll look it up later, maybe) said that Sun currently views JDO as an intermediate layer between JDBC and an entity bean. This is in contrast to what I'd thought Sun originally suggested JDO would do, which was to replace entity beans.
[ June 12, 2003: Message edited by: Dirk Schreckmann ]
Craig Russell
Author
Greenhorn

Joined: Jun 16, 2003
Posts: 28
By proprietary, I mean that they have their own API that is used with their own product.
With JDO we took the approach of defining interfaces that could be implemented by any number of implementations from different vendors. The architecture is deliberately pluggable. There are over a dozen implementations of the JDO API.
The user defines the data model; the JDO specification defines the access interfaces for queries, transactions, and life cycle (CRUD) operations.
Originally posted by Gregg Bolinger:

How are they proprietary? Could you elaborate a little bit?
Ed Trembicki-Guy
Greenhorn

Joined: Mar 19, 2003
Posts: 7
Originally posted by Craig Russell:
...Craig Russell's view is that to build scalable Web applications, the best use of JDO is in conjunction with JSP pages for display...

There isn't anything that necessarily couples JDO to a particular presentation layer implementation, is there? I'm finding Tapestry more compelling for presentation than JSP, and would assume that I could use any persistence strategy, JDO included, as easily as someone using Struts for presentation.
-Ed


The things I did not know at first I learned by doing twice. -Billy Joel
Craig Russell
Author
Greenhorn

Joined: Jun 16, 2003
Posts: 28
JDO is generic persistence that because of its architecture is suitable for one-tier, two-tier, and multi-tier applications. You are right that there is nothing in JDO that ties it to any presentation layer.
You will probably find that many of the patterns used with JDO/JSP can also be used with Tapestry. I must admit I know nothing about Tapestry, but generally JDO provides persistence to other layers, and is not tightly coupled to any of them.
Originally posted by Ed Trembicki-Guy:

There isn't anything that necessarily couples JDO to a particular presentation layer implementation, is there? I'm finding Tapestry more compelling for presentation than JSP, and would assume that I could use any persistence strategy, JDO included, as easily as someone using Struts for presentation.
-Ed
Lasse Koskela
author
Sheriff

Joined: Jan 23, 2002
Posts: 11962
    
    5
Originally posted by David Jordan:
The JDO application code will be binary compatible across these different JDO implementations.

Aren't the JDO implementation doing some byte code modification in order to provide their functionality? Doesn't this break binary compatibility as the byte code contains vendor-specific logic?
Chris Mathews
Ranch Hand

Joined: Jul 18, 2001
Posts: 2712
Originally posted by Lasse Koskela:

Aren't the JDO implementation doing some byte code modification in order to provide their functionality? Doesn't this break binary compatibility as the byte code contains vendor-specific logic?

The byte-code enhancements are explicitly detailed in the JDO Specification so that it remains vendor neutral. Furthermore, enhanced classes from any vendor are required to work (without modifications) with other JDO vendor. I believe this scenario is tested for in the JDO TCK.
David Jordan
Author
Ranch Hand

Joined: Jun 14, 2003
Posts: 66
The JDO enhanced classes contain a reference to an instance of a class that implements the StateManager interface. This object is vendor-specific, but the interface is part of the JDO standard. All the bytecode enhancements do their work through this StateManager interface. So the resulting enhanced classes are vendor-neutral. This StateManager reference gets initialized when you first make an object persistent, or is initialized when it is read from the database.
Lasse Koskela
author
Sheriff

Joined: Jan 23, 2002
Posts: 11962
    
    5
Ok. Have I misunderstood something as I'm pretty sure I've heard people say that JDO implementations differ in the way they modify the byte code?
Assuming I would write an application using TJDO and later on decide to switch into Kodo JDO, would I need to redo the build process (the byte code is already portable, right)? David, could you please elaborate on the way JVM manages this "reference to the StateManager"?
[ June 17, 2003: Message edited by: Lasse Koskela ]
David Jordan
Author
Ranch Hand

Joined: Jun 14, 2003
Posts: 66
All vendor-specific enhancers are supposed to support the standard reference enhancement contract. You are supposed to be able to enhance with any vendor's enhancer and it will work with any other vendors's runtime. A vendor may add additional things to the byte code that are strictly used with their runtime implementation to provide optimizations, but these are NOT supposed to get in the way of that class being used by another implementation. Having said that, if you are switching from one vendor to another, you are more than likely going to use their enhancer. I believe most implementations, while they do have their own enhancer, this is primarily done so that they can do the "schema capture" of class information. I believe most are simply adding the same code as the reference enhancer.
Whenever an instance gets associated with a PersistenceManager of an implementation, it has the StateManager reference set to reference that implementation's StateManager. A double dispatch pattern algorithm is used between the instance and the StateManager to coordinate the state within the instance. Again, this is what causes JDO to work and also allows it to be vendor-neutral, but it is something you really never have to worry or think about when using JDO. But I can appreciate your desire to understand the underlying mechanisms. Our book only provides a VERY highly coverage of this because it is not something the average JDO developer will ever need to worry about, or even some not-so-average developers. As long as you are dealing with a compliant enhancer and implementation, things work just fine.
Lasse Koskela
author
Sheriff

Joined: Jan 23, 2002
Posts: 11962
    
    5
David, you do have the talent of making JDO sound attractive
The fact that JDO-enhanced classes are binary compatible is great news for me (I always thought you'd have to recompile the source, enhance it, and redeploy your application in order to switch the JDO vendor).
I do realize it's definitely the common approach to adopt the enhancer along with a new implementation of JDO. What I was after with the question was more like "what if I want to write a JDO application (myapp.ear) that can be deployed on any appserver using any JDO implementation". Did I understand correctly that this is the case?
Thanks.
[ June 18, 2003: Message edited by: Lasse Koskela ]
David Jordan
Author
Ranch Hand

Joined: Jun 14, 2003
Posts: 66
Assuming each JDO implementation you want to use will have integration with each application server, it is supported to work at a Java level. But you will still have property files, XML metadata, and other similar things that will differ among JDO/application server implementations. This is true when using different application servers anyway, without use of JDO.
I am not trying to "sell anyone" on JDO, I am just giving you the straight facts, as I understand them. But I also really believe in this technology, that it offers great productivity and it is a real pleasure to work with compared to the alternatives. I encourage you to try it and you will see for yourself. Take a Saturday or Sunday afternoon and use the reference implementation to get a small object model stored and accessed. You'll see.
Rajeev Ravindran
Ranch Hand

Joined: Aug 27, 2002
Posts: 455
hi ranchers,
i have heard of book promotion by javaranch and heard that some will get the new book , im sorry im sorry if im mistaken !!
so what shld i do to get a chance in winning a book ??? wat is the criteria for selecting the winners ???shld i post any JDO related questions ??? if that is the case i doono wat to ask !! i wish if i cld get more info regarding JDO..

raj
SCJP


SCJP, SCWCD, SCBCD, Oracle Certified Professional (SQL n PL/SQL)
Craig Russell
Author
Greenhorn

Joined: Jun 16, 2003
Posts: 28
Just a few comments. When you deploy an application to a different vendor's server, the amount of work you have to do varies based on the requirements of your application and the features you have chosen to use.
This applies to EJB components as well as JDO classes. While application servers give you the opportunity for highly portable code, the deployment aspects of the environment come into play when you switch vendors.
For example, there may be vendor-specific deployment descriptor information especially for CMP beans, as the mapping to the datastore is not standardized (either in CMP or JDO). Further, configuring your resources (DataSource or Connector Architecture or PersistenceManagerFactory) is not standardized across implementations.
What you will find with JDO is similar to other components -- you can use the JDO classes and the Session beans in your .ear file without change, but you will have to tell the JDO implementation where to find the information and how to configure the PersistenceManagerFactory.
Originally posted by Lasse Koskela:

The fact that JDO-enhanced classes are binary compatible is great news for me (I always thought you'd have to recompile the source, enhance it, and redeploy your application in order to switch the JDO vendor).
I do realize it's definitely the common approach to adopt the enhancer along with a new implementation of JDO. What I was after with the question was more like "what if I want to write a JDO application (myapp.ear) that can be deployed on any appserver using any JDO implementation". Did I understand correctly that this is the case?
Thanks.
Lasse Koskela
author
Sheriff

Joined: Jan 23, 2002
Posts: 11962
    
    5
David/Craig, that's basically what I wanted to hear. I wasn't expecting no-configuration-at-all but simply code portability. It would be nice to have the JDO mappings standardized (no need to touch any application logic including persistence mapping definitions) but I think that's something we can live with.
By the way, how does the deployer configure datasources for an application utilising JDO? I mean whether the application assembler is able to define some kind of resource-ref entry so that the deployer knows that she'll need to configure a datasource for the JDO PersistenceManager as well.
David Jordan
Author
Ranch Hand

Joined: Jun 14, 2003
Posts: 66
Here is just one example.
But don't take this as a pro/con statement for this particular vendor, this was just handy to
show you an example.
The following would be placed in a service.xml file and placed in the JBoss deploy directory:

The name RubisPMF is used to look up the PMF service.
The file jdo.properties contains the information
to configure the PersistenceManagerFactory as well as other vendor-specific properties.
Then here is one session bean entry from the ejb-jar.xml file:

It references the resource RubisPMF, identified above.
The actual session bean does a JNDI lookup on RubisPMF and it gets a PersistenceManagerFactory returned. The content of the above code samples will be different for each JDO vendor.
Lasse Koskela
author
Sheriff

Joined: Jan 23, 2002
Posts: 11962
    
    5
Thanks, David.
 
wood burning stoves
 
subject: JDO
 
Similar Threads
Any ideas of JDO??? it looks good!
Which JDO implementation do you recommend?
Wich JDO implementation to use?
JDO question.
Hibernate vs JDO