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.
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.
The ENIAC Demo Competition
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.)
SO YOU'RE GOING TO DIE: The Comic for Dealing with Death
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
I read this and thought that it was very much a downer on C++. In fact the authors even go so far as to suggest that Java is simply better in all but the rarest of cases. There is also a brief mention of JDK availability and also VMs in Red Hat, but I really didn't see how this was relevant.
Tell it which objects are mapped to which tables? And what about objects that map to multiple tables? Seems like you'd still have to have SOMEONE who knew how to do a proper database schema to set up your object structures and mappings, and make the database itself. :)
That said, this would free your developers from having to be intimately knowledgable about your database schema, which, if you have done any outsourcing, you would recognize the benefits of right away.
That is precisely the problem with the majority of non-JDO persistence architectures that use standard reflection (Toplink, Hibernate, CocoBase, Castor). While people tend to get nervous about bytecode enhancement, it is just an additional step in the compilation process.
Bytecode enhancement allows JDO to perform change tracking without intruding on the application. Reading 1000 objects in a transaction and changing a single one, a reflection based framework will need to perform comparisons on each and every field of each of the instances. JDO will just need to do a single one. Reflection-based persistence frameworks are fine for "hello world" applications, or if you do not mind intruding persistence details into the application, but for true transparent and scalable persistence, JDO is the way to go.
Of course, there are many other comparison points between persistence frameworks, such as the degree to which JDO is datastore-agnostic, the number of JDO vendors vs. non-JDO vendors, the issue of JDO being based on an increasingly important standard, the lack of vendor lock-in, etc. Many of these issues are discussed on JDOcentral.com
There are several Object-Relational mapping packages for Java out there. Hibernate is another one.
However, I have to say, that I have not found any complete O/R mapping package that implements everything transparently. In specific, I'm talking about recursive map structures, and "long transactions". Most of these packages are aimed towards short lived transactions on one object, or on a unidirectional tree of relationships.
I sunk absolutely OBSCENE amounts of time and effort into trying to make various packages work with a many-to-many self-recursive database structure only to realize it cannot currently be done with the packages out there. I would be glad to be proven wrong.
I would love to be able to keep a cache of a recursive map structure in memory (indefinately!) and have modifications automatically cascade the required updates to all nodes and revoke/expire any checked out nodes.
Finally I gave up trying to cache the actual structure in memory and now I just cache data, descend over the structure in the database for each request (it's not so bad, it turns out to be rather fast anyway).
It's 10 PM. Do you know if you're un-American?
To have an honest book review, you should read the full book. Unfortunately, it's very difficult to fully read a book when it sucks.
So maybe this is the reason slashdot readers review only books that rule...
If you want to get a technical feel for JDO, Solarmetric has an online document that covers all the spec basics here. It's not as in-depth as a full JDO book, but it covers JDO concepts pretty nicely in about 40 pages (if it were printed).