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.

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 [bluemars.net] 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.

good book, bad topic

[Anonymous Coward]

I read this book a couple weeks ago. It's a good book (some o'reilly's are essential, some were a waste of paper and ink, and some are good). However, Java Data Objects should be avoided if possible.

I know that sounds like a harsh statement to the uninitiated. I'll admit, the idea sounds good. But the implementation is a headache and maintenance nightmare.

I've worked with Java Data Objects for 3 years now, and everyone I know who has experience with it feels the same.

Re:JDO vs EJB Entity Beans?

[ideonode]

There's an interesting thread [theserverside.com] 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?

[Brian Blessed]

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" [jboss.org] (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

Another Query Language

[boxhead609]

I am concerned about learning another query language. Each has its limitations and that is why I was slow to adopt EJB-QL. EJB-QL is odd to learn and still not as feature rich as pure SQL. Now there's JDO-QL... yet another query language to learn. I found that in my previous projects, it is not that bad to embed SQL into DAO objects. You have complete power and control that way. You don't have to learn another QL, and you have the benefits of SQL.

Alternatives

[tdrury]

Before you commit to JDO or entity beans, do yourself a favor and also look at OJB [apache.org] and Hibernate [bluemars.net]. 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.

Re:good book, bad topic

[mprudhom]

I've worked with Java Data Objects for 3 years now,

FUD. The specification was released only one year ago [jcp.org].

and everyone I know who has experience with it feels the same.

FUD. See JDOCentral.com [jdocentral.com] and TheServerSide [theserverside.com] for real-world discussions.

Re:JDO vs EJB Entity Beans?

[javajedi]

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.

Apple's Enterprise Object Framework

[Agave]

Object-Relations Mapping isn't very new, even in the realm of Java. Apple, TopLink, CocoBase, have been there for years without JDO. I haven't had much time to evaluate JDO but I'd be surprised if it's as well designed or as comprehensive as Apple's Enterprise Objects Framework [apple.com] and EOModeler [apple.com].

EOF is available with WebObjects [apple.com] which is a much easier way to build 100% Java web applications than any jsp/ejb solution.

in summary:
Object-relational mapping - good.
WebObjects/EOF - good.
JDO - undecided.

Re:good book, bad topic

[Anonymous Coward]

Castor IS NOT Java Data Objects. Caster does not follow the specification for Java Data Objects.

Repeat.
Caster is NOT Java Data Objects

Re:JDO vs EJB Entity Beans?

[MSBob]

1+n lookup issue that you're referring to has long been resolved in CMP2.0. Move on.

OJB is better...

[JohnnyCannuk]

While JDO is interesting, the Apache OJB (Object Relational Bridge) [apache.org] project is even better. It provides a JDO implementation as well as an ODMG impelemtation and a low level PersistenceBroker API. Lots of choice. More than one way to do things, allowing the developer to trade-off make trade-off when they are appropriate. It is fully transactional and supports the latest JDO as well as ODMG specs.

And it can be used to persist objects transparently...you can set it up to persist objects you already have and completely control how the object relation mapping takes place in a few config files.

We've used it on projects since November, and I don't think we'll ever go back to Entity Beans. This project allows you to choose when you would like to use byte code enhancment techniques (JDO) or reflection techniques(ODMG) or even combine the two.

Best of both worlds.

Re:JDO vs EJB Entity Beans?

[deogee]

Try hibernate http://hibernate.bluemars.net.
Inheritance, composition, lazy loading, proxies. Very easy. Sun seems to treat JDO as the black sheep of the J2EE family and who knows what they'll do with it. Besides, there's no truely compliant open source implementations availible.

Toplink is becoming JDO

[olip]

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.

JDO usability

[elindauer]

I've been working with JDO essentially since it was released, and have found it to be a very effective tool. As with any technology, it takes some time to learn, and it has areas which aren't as transparent as you'd like them to be.

I have always been the "JDO-guru" for my development team. As such, I've spent a lot of time trying to smooth out the various issues we've run into, so that other members of the team can work with this technology as transparently as possible. The main thrust of this work has been to make transaction handling easier, and to deal with PersistenceManagers. My company has been generous enough to allow me to open-source this work (which I've named "Stomp"), so if you are serious about using JDO, you may want to check it out [slashdot.org]. Even if you don't use the code here, there is a page explaining how Stomp works [sourceforge.net] which describes the motivation behind this toolkit, the problems we ran into, and how we solved them. You'll have to solve similar issues yourself if you use JDO, so this might be a good way to get a handle on what you'll face when you use JDO.

This stuff works very well for us, but of course has the risk of being non-standard. Even if you don't use Stomp, the ideas presented may help you use JDO more effectively.

PS Stomp is written to work with Kodo (from Solarmetric) but could easily be made to work with other JDO vendors. Write to me if you are interested.

Re:ado??

[f00zbll]

Bussiness customers notice this. Especially if project deadlines are always a problem. The quicker something is done the better.

I'll bite. Although this statement may seem accurate it is not. Let's take for example companies that provide application services, be it insurance, financial or enterprise resource management. There's nothing wrong with hardcoding everything and removing abstraction layers all together, if the application will stay that way for 1-2 yrs. Having said that, none of the projects I've worked on had static requirements. If anything, the requirements change rapidly. Hardwiring everything in the petshop demo mean you'll have to change 50-80% of the code to support a new feature.

putting in abstraction layers increase code size right. adding comments to your code so that it is self-documenting and easy to maintain adds to the code size also. It's great model of development if your goal is to charge as much as possible and spend 80% of your time maintaining and fixing the system. It only works if you don't have competitors. If some one else take 15% more time to build the same system, but their maintenance cost is only 25%, you'll loose the battle in the long run. So the quicker something is done isn't necessarily better.

If sun was smart they would release newer libraries to compete with C#.net as well.

This statement is mis-informed. there are plenty of libraries that provide better standard compliance to XML, SCHEMA, and SOAP in Java than Microsoft. Try to do Object-relational mapping that follows standard OR techniques. What I mean by this is, take relational data and map it to an object hierarchy which reduces repetition/duplication of values. Guess what, if you use the stock VS.NET tool it only generate flat tables. This means rowsets that have similar/same columns will be duplicated. this is because ADO flattens everything and doesn't maintain OR mapping, therefore the Schema tool in VS.NET generates flat tables.

I could be wrong, but every time I've tried using VS.NET schema tool with database tables that is what it does. The only way to get around that is to build your own OR mapping and write the schema by hand using complexTypes instead of elements the way VS.NET does it.

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.

Re:JDO vs EJB Entity Beans?

[rossifer]

JDO is a massive step up from EJB entity beans, giving you inheritance, sophisticated state behavior, fairly low overhead (especially at the object layer) and several advantages besides.

But JDO's goal, of insulating you from the database, means that you can't get to the database even if you need to. In my opinion, this limits JDO apps to the same "toy" class of applications that entity EJB's are limited to.

For instance, the way JDO stores a polymorphic reference is to store the object id and the object type (as a text string with the fully qualified class name) as two separate columns in the referrer's table. That's horrible in several ways (including db bloat and the fact that you've lost most of the ability to report against the database), but because the JDO spec refuses to let you give it any hints, it has very few other options. This particular problem made JDO infeasable for the last app I worked on (a security manager that pulled in 30-50 million snort events per day). JDO would have doubled the database size, on a database that grew at 2-3GB/day!

Other solutions, like Hibernate [bluemars.net] or OJB [apache.org] give you the ability to ignore the database if you so wish (by providing schema generating tools) but also give you the option of writing a great object model, writing a performant database schema, and then describing the best possible mapping between them. And believe me, when it comes time to make your application scalable to hundreds of simultaneous users and hundreds of millions of rows, you'll appreciate the ability to design the database yourself.

JDO's real problem is that it pretends that there's no need for relational programming now that we've got object oriented programming and it's another restatement of the object-oriented database. Relational programming has several distinct advantages over OO programming in several problem areas, the most obvious being arbitrary search (which the OO model intentionally prevents with encapsulation). True object relational mapping tools don't make this mistake. They let the object model do what it's good at, the data model do what it's good at, and then help them talk to each other.

One thing that JDO did do a good job of was the application interface. The query is nice and the rest of the semantics are clean. And luckily for the rest of the world, there's no reason why an ORM tool can't provide a JDO interface but do the mapping more intelligently. In all actuality, this is what will happen to JDO very shortly (if it already hasn't). The vendors will provide systems that comply with the spec and then customers will demand that they have more control over the db and mapping and each vendor will extend their implementation in some nonstandard way to give them that power.

Regards,
Ross

Re:JDO vs EJB Entity Beans?

[Mindbridge]

Here is a one that is under Apache license: TJDO [sourceforge.net]

And this one is free for non-commercial use: Libelis [libelis.com]

Also, there are a number of open source implementations that are "in-progress" -- Apache's Object Relational Bridge [apache.org], etc.

This is one thing about Java that OSS advocates should appreciate -- open specs, multiple implementations. Standardising less than 10% of your APIs without commitment to allow competing implementations to the rest of the platform is simply showmanship.

Re:JDO vs EJB Entity Beans?

[awhite]

Actually most relational JDO implementations already let you bypass the JDO layer and deal with SQL when you want to, and let you map classes to an existing schema (or even generate classes and O/R mapping data from an existing schema). At least, I know you can do all this with Kodo JDO [solarmetric.com]. If you haven't checked out JDO lately, I'd say you should give it another shot. Keep in mind that the spec is barely a year old... implementations are adding features very rapidly.