Java Data Objects

Reader java1dev submits the following brief review of O'Reilly's Java Data Objects, which he says provides excellent coverage of JDO. His capsule description of the book: "First, a high-level overview, followed by an in-depth coverage of the core features, and concluding by describing the more complex concepts in detail. Running throughout the book is an excellent intuitive example application that illustrates the features being covered." Read on for more of his review. Java Data Objects author David Jordan & Craig Russell pages 356 publisher O'Reilly & Associates rating 9 reviewer java1dev ISBN 0596002769 summary Excellent, example-filled introduction and practical guide to 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.

Comments

suggestion

[newsdee]

Would it be possible to add the suggested retail price (MSRP) of a book in a review?
Yes, it can be found by searching the web, but it's just extra comfort brought by a small database tweak. :-)

JDO vs EJB Entity Beans?

[kisrael]

I've heard that JDO is much better, tighter solution to O/R mapping than EJB Entity Beans, that the latter are designed to be SO flexible that you can use them as a wrapper to your legacy mainframes, but the former is a lot closer to the problem most Java folks need to solve. Anyone know if that's a reasonable viewpoint?

(For the record, at this point I hate, hate EJBs. I think they're speficially responsible for the failure of multitudinous Java server projects, way to much overhead for 95% of all things you'd want to do in Java on the server, and the bad apple that risks spoiling the whole J2EE barrel.)

Re:JDO vs EJB Entity Beans?

[ideonode]

There's an interesting thread over at TheServerSide which discusses JDO vs. Entity beans.

Re:JDO vs EJB Entity Beans?

[haystor]

I've been using torque (from Apache, under the DB project).

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");
Empl oyee emp = new Employee();
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.

Re:JDO vs EJB Entity Beans?

[awhite]

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.

If you read a lot of Marc Fleury's public comments carefully, it is clear that he doesn't know what JDO is. He equates JDO with Castor JDO, which is a relatively simplistic persistence solution that happens to have "JDO" in its name; it is not a Java Data Objects implementation. The quote above is a perfect example: the JDO spec is barely a year old! So JDO was not widely used a year ago: Castor, however, was getting a lot of publicity around that time.

Fleury would do well to research the JDO spec, because a lot of the things he's proposing in his new vision for CMP are things that real JDO already does. JDO can persist vanilla Java classes with no code changes. Persistent fields and relations are completely transparent. Just declare a field of some other persistent type, and the relation is managed for you. Same with Collections and Maps and so forth (including collections and maps of relations to other objects). Data is lazily loaded as you access it, and change tracking is automatic. The runtime API for managing persisting objects consists of only a few classes. The query language looks just like Java boolean expressions. The whole system is elegant, but powerful. It stays out of your way. It's everything EJB is not :)

JDO

[HunkyBrewster]

"In brief, Java Data Objects (JDO) insulates you from needing to know a lot about databases."

First of all, I wouldn't want to hire that developer. Secondly, that is not entirely correct. O/R frameworks are useful in that they provide a consistent interface

Java Data Objects are nice but Hibernate is Better

[TheNarrator]

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.

Well, for those who missed it

[WndrBr3d]

I've said it once, and i'll say it again.

These book reviews on Slashdot, at times informative, really just are letting people know about the book and not as much reviewing that.

This demonstrated is that in the last two months, no book has received less than a 80% approval rating by the author (unless you rate a 'very good' as < 8). It's like Homer Simpson is writing these reviews, "This (book) gets my lowest rating ever, seven thumbs up."

I mean honestly, a review needs to have a few lemons on its record. I think someone should review a Wrox book on Linux and have it summarized with, "This book really gobbled the cob. it wouldn't be fit to line the kitchen floor for my puppy to soil in the evenings."

Instead of calling it 'Slashdot Book Review', it should just be called 'Slashdots list of books that rule'.

That's just my opinion though, I could be wrong.

Alternatives

[tdrury]

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 again?

[geoff_hendrey]

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.