Slashdot Mirror
Java Data Objects
Craig Russell, at Sun Microsystems, is the specification lead for JDO and David Jordan, at Object Identity, has been an active member of the JDO expert group since its inception.
Java Data Objects provides a thorough coverage of JDO and explains how it can be used in various architectures. The reader is expected to be familiar with Java but needs only a limited knowledge of databases. In brief, Java Data Objects (JDO) insulates you from needing to know a lot about databases. JDO permits you to develop applications using your preferred Java object-oriented model, without you having to write code to translate between Java objects and how the data is stored in the database--JDO takes care of all of that for you.
The first three chapters provide a high level overview of JDO by walking through a small application, exploring each of its interfaces at a high level, and introducing the architectures it might be used in. Even if you have been away from code for a while you will be able to follow most of the code example. You can stop here if you just want to understand what JDO is all about and where it can be used. These are recommended reading for a manager.
Chapters 4 through 9 are required reading if you want to start developing JDO applications. They really get you into JDO, so you can understand it and start using it. The first three of these cover how to define persistent classes and fields, how they can be mapped to various databases (done for you) and the class enhancement process (which makes a lot of JDO transparent to you). The next three (chapter 7 through 9) bring home the power of JDO. These cover how to connect with a database, establish a transaction context and create, read, query, update and delete database objects. The material is made concrete by illustrating it with a detailed and intuitive example application. This example is carried throughout the book with sections of it explained as the concepts are covered.
Each remaining chapter covers a different JDO concept or feature (including optional features) that were introduced earlier but not covered in detail to keep the earlier chapters more understandable. These remaining topics are identity, lifecycle states & transitions, field management, cache management, nontransactional access and optimistic transactions. You can read these chapters as you feel the need for a more in-depth understanding of these concepts.
The last two chapters explain how to use JDO in an application-server environment and an Enterprise Java Beans environment. These two chapters assume you are already familiar with these environments, but I think a lot of it is understandable even if you are not.
There are five appendices with everything from the lifecycle state transitions to the collected source code for many of the classes used in the example application.
You can purchase Java Data Objects from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.
I looked into JDO and was excited. Here was a much simpler alternative to EJB. In EJB there are many many things that can go wrong during deployment of beans which leads and quite a bit of replication. YOu define your object once in the bean, once in the remote interface, once in the local interface, etc. It seems to take a while to debug. JDO is better but it requires a class file enhancer. Hibernate is a lot better. There is 1 config file that defines your whole object model and it requires no special class file enhancer. That and unlike EJB it supports inheritance in object models well.
There's an interesting thread over at TheServerSide which discusses JDO vs. Entity beans.
I've been using torque (from Apache, under the DB project).
l oyee emp = new Employee();
One row in the db equates to one object with all the appropriate getters and setters.
I haven't been using Torque for anything too complicated, but it definitely passes the test of making the simple things simple, and area I find Java to be weak in.
For instance:
Torque.init("Torque.properties");
Emp
e.setName("Dave");
e.save();
That's all there is to creating a row in the db. There are correspondingly simple operations for select, update and delete so long as you are working on one table at a time. Its a bit messier working with joins.
Its also messy and poorly documented when doing work on the select side of the statement. While "select max(emp_id) from employees" is doable, its not as simple as it could be considering how common select max() is.
t
I've heard the opposite.
Of course he's biased, but Marc Fleury (of JBoss) is very enthusiastic about CMP (Container Managed Persistence) v2.0 EJB's.
In his "Blue" Whitepaper on the subject he wrote that the CMP (Container Managed Persistence) v1.1 of EJBs was seriously lacking in various critical aspects, and goes on to say the following:
From Marc Fleury's "Why I love EJB's" (PDF, page 7):
In other words, if the CMP2.0 engine s applicability goes beyond EJB alone, why couldn t we imagine a CMP engine working on abstract plain old java objects? We will look at making it the default service for persistence in JBoss. In fact I would argue that CMP2.0 is doing what JDO failed to do, providing a robust and frameworkworthy persistence engine for java (once generalized). While it was widely used in designs a year ago, JDO will probably go down in history as the proverbial chicken that crossed the road when the CMP2.0 truck came along.
- Brian
Before you commit to JDO or entity beans, do yourself a favor and also look at OJB and Hibernate. Both of these object-relational mapping (ORM) tools offer unintrusive presistence to your existing beans (unlike Toplink and Cocobase which require you use their collection types) and don't require you to run a byte-code mangler like JDO.
FUD. The specification was released only one year ago.
and everyone I know who has experience with it feels the same.FUD. See JDOCentral.com and TheServerSide for real-world discussions.
I did a pretty extensive evaluation of both. Turned out the 2 technologies were very similar, as long as you use XDoclet with CMP Entity Beans. JDO's biggest advantage over CMP is built-in support for polymorphism and inheritance. CMP Entity Beans' biggest advantage over JDO is Container Managed Relationships. The code base for both sets of code was basically the same. JDO doesn't have declarative transactions, but I was able to simulate this using an Aspect. We ended up going with EJB, largely because it was more mature, and more good, open-source implementations existed (e.g. JBoss). There isn't even a full open-source JDO implementation yet.
We are going live with the first release of this system on Friday, and the CMP Entity Beans are working like a champ. I'm really sick of people complaining about how terrible Entity Beans are. Everyone who does is either using a crappy implementation or doesn't understand how to use them right. There is nothing "tighter" about JDO.
Castor IS NOT Java Data Objects. Caster does not follow the specification for Java Data Objects.
Repeat.
Caster is NOT Java Data Objects
Comparing is not the best way to go.
From what I've heard, Toplink is due to implement somehow the JDO specs in a few months.
Seems they are trying to change the spec (making the "code enhancement" feature optional), since enhancement is not the way they have chosen. And since they are backed by Oracle, their voice has become louder.
Probably there will be two levels of JDO spec : level one for Toplink, level 2 corresponding to JDO as we now know it.
Anyway JDO is the thing all Java developpers have been waiting for, especially those who have tried EJBs : a well designed framework. And the transactionnal cache feature (in some products, like Lido) may lead to excellent perfs for most apps.
here we go with the FUD again. "Mangler"??? I suppose you consider javac a "mangler" or aspectj a "mangler". I think the "mangler" you refer to is the bytecode enhancer. What you forgot to mention is what the "mangler" does. Rather than scare people off, I'd like to explain the clear advantage to bytecode enhancement over reflection for dirty detection. Let's say you do a query which returns a single object. Your application then modifies a single field of the object and commits the transaction. Before commit you have to perform "dirty detection" to find out what fields have been dirtied, and need to be updated in the DB. If you don't use an enhancer you have to compare the object, field by field, with either a cached copy of the object, or worse, issue a select into the database to get the old values. The latter is particlularly bad not just for the obvious performance hit, but because it forces the table or rows to be locked for the duration of the transaction, thus making optimistic transactions impossible. Now imaging your select returned 100 objects, or 1000 objects. With an enhancer, the bytecodes for 'putfield' and 'getfield' are replaced with calls to the bvendor provided state manager. The JDO driver knows instantly what fields were dirtied, needs to keep no cached copies and never hits the database with a select before update. Furthermore, with enhancement you don't force the user to extend any classes. There is zero intrusion on the domain model. I understand that Castor, Hibernate, etc. are good open source projects, and very viable. I do, however, think that JDO is elegant and has advantages, on paper at least, over other methods.