Hibernate - A J2EE Developers Guide

Simon P. Chappell writes with a review of the Addison Wesley-published Hibernate - A J2EE Developers Guide. "To quote the project website: 'Hibernate is a powerful, ultra-high performance object/relational persistence and query service for Java.' To quote the back cover of the book: 'Now there's a practical, hands-on guide to using Hibernate's flexible, fast object/relational persistence and query services.' Phew! What a lot of spin packed into two sentences. Let's take a look and see if it delivers." Read on for the rest of Chappell's review. Hibernate - A J2EE Developers Guide author Will Iverson pages 351 (13 page index) publisher Addison Wesley rating 7 reviewer Simon P. Chappell ISBN 0321268199 summary Overall a solid work

What's To Like

The first thing that I liked is the way the book is written. Mr. Iverson has a very pleasant writing style that I found engaging. Not too formal and not too light. Naturally, there is a certain amount of Hibernate evangelism, but hey, if the author doesn't like the tool, then how am I supposed to feel good about it either? The evangelism does not feel like it strays from the bounds of truth, and there is much honesty in his first and last chapters where he discusses reasons for using a tool like Hibernate, and how Hibernate has influenced the design of the soon-coming version 3 of the EJB standard from Sun.

Chapters two, three and four cover the basics of using Hibernate. Each covers a different aspect, and each is independent of the other. Chapter two covers the use of the Hibernate mapping file as the reference that everything else is built from. This is the recommended mode of operation, where the database schema and data access objects are built for you. Chapters three and four are for those of us in the corporate world where the code or the database schema comes first and we have to adapt to and accommodate it.

Chapters seven and nine give the database theory-challenged amongst us a useful refresher in database relationships and transactions. The information, while provided in the context of Hibernate, serves as a useful refresher for the rest of us.

Hibernate has three query mechanisms. Given its relational database capabilities, one of the options is the use of plain old SQL, naturally. The two remaining options are the Hibernate Query Language (HQL) and the Criteria API. The HQL gets a fairly decent amount of coverage and left me to infer that it is the preferred means of expressing queries. The Criteria API gets only four and a half pages of explanation, which is still more than the single page dedicated to SQL.

The next to last chapter is a collection of real-world advice and tips for getting the best from Hibernate. This is a very useful chapter and looks like it contains good advice. The only thing I would suggest is that it's a little slim for a chapter of its own. Either the information could have been tucked in an appendix, or it could have been spread through the book in the form of embedded tips.

Naturally, the book has a website to accompany it.

What's To Consider

The book carries a copyright date of 2005 and a first printing date of November 2004. That being said, it should come as no surprise that the version of Hibernate covered is 2.1.2, but at the writing of this review (early April 2005) Hibernate 3 went final. I feel that the majority of the concepts and basic operations will be unchanged, but take this into account when deciding upon a purchase. While it is difficult to write books against the constantly moving target of an open-source or free software project, it is possible. I was involved in the technical review of a number of Struts books and they were challenged with the task of being available as version 1.1 was released. A massive undertaking, but one that they proved doable.

The typesetting seems crowded in this book. I'm not a white-space extremist, but I sure recognise when there's too little. The listings are often multi-page and have a slightly squashed feel to them.

Depending upon your point of view, chapter five is either a very useful annotated explanation of all of the available mappings within Hibernate, or it's a bad case of using available online documentation as filler (53 pages). Personally, I dislike this, but if you're in the market for an "all-in-one" style of book, this might work for you.

Summary

This is a solid work that will take you from novice to a good working knowledge of Hibernate. If you can live with the fact that the book targets Hibernate 2.1.2 while the current production version available from the website is 3.0, then give this book a try.

You can purchase Hibernate - A J2EE Developers Guide 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

Is it better than Hibernate in Action?

[Babar]

I can't believe a review of a book about Hibernate would not compare it to the book everyone recommends, Hibernate in Action. HiA is a great book, written by people who work on the project, including the lead developer. Of course, this review doesn't have much information that couldn't be obtained from skimming through the table of contents on Amazon.

Java never got a fair break.

[Future Man 3000]

People tend to notice its flaws (oh it's so slow!) because it's the first iteration of its technology, but it is still an excellent tool for getting the job done regardless of its platform.

Is it going to be replaced by C#? Perhaps, but it is possible to fully exploit it today, and with tools like Hibernate it's possible to rapidly deploy applications on a grand scheme. In today's business environment it is often a matter of getting it done fast rather than best, and if it's turning into a problem with performance it is always possible to turn to another language once you have something in place.

Re:Java never got a fair break.

[Lysol]

Is it going to be replaced by C#? Perhaps,...

Doubtful. I'm sure C# will get quite popular, but neither that nor will Mono have a foothold on the server like Java does anytime soon. Java's tools and microcosm of open and closed projects are being used by quite a bit by companines and organizations doing real, every day work. Granted, Java on the desktop never took off, but the whole C# vs. Java war is just a myth - there's plenty of room for both to exist.

I'm using Hibernate on my current project and while it's not the be all/end all, it's definitely a better approach (I feel) than EJB entity beans. 99% of my current data layer is Hibernate code/classes and I'm pretty happy with it. Coupled with various plugin caches and you have a fast, reliable data access layer.

Once you get the nuances of Hibernate, it's quite easy and sometimes even fast to plug in an entity and go. Remember, it's not just wrapper for JDBC/Transactions, etc, but a fairly mature and robust ORM solution. And, its HQL (yes, another QL) allows for fined tuning of any entities that might become a bottleneck.

For med to big sized projects, I'd recommend it.

Re:Java never got a fair break.

[Decaff]

Easy things easy. Hard things possible. Java's got one. RoR nails them both. Bloggers seem to be buzzing about it right now, but in time it's going to be absolutely huge.

Not in it's current form it won't. RoR has some serious design flaws for major projects. One is that the object model is derived directly from the database, so if the database changes even slightly, this can seriously break code. Serious ORMs have mapping configurations that allow the object model to be isolated from such changes. This hard link to the database also prevents easy portability between different database types - a schema change required by porting can again break code.

Serious ORM systems (such as Hibernate and JDO) have the ability to fine-tune the loading of fields to prevent serious memory and performance problems. Imagine trying to use RoR for large datasets where the tables included large BLOB or VARCHAR fields - this would be a performance nightmare.

The RoR people don't seem to understand that the configuration files present in large Java ORM applications are there for a good reason - to abstract and fine-tune database access.

Finally, RoR requires use of vendor-specific SQL. JDO and Hibernate abstract this. Moving a JDO or Hibernate project between, say MySQL and PostgreSQL can be very fast. It could be a major problem with RoR.

RoR takes a very old-fashioned database-centred vendor-SQL-specific approach.

Hibernate and J2EE

[cmiles74]

I am curious to know if this books spend a decent amount of space on actually using Hibernate in the context of a J2EE application (i.e., instead of using CMP)? I currently work with CMP and I am not a huge fan, I am very interested in alternatives and wonder if this book is the place to start looking.

The title of the book implies that the book does cover this, but the review doesn't actually mention this specifically.

Re:Hibernate and J2EE

[chochos]

My quick recipe for that is:

1. Screw EJB and CMP
2. Use Spring instead of EJB's (or in conjunction with EJB's)
3. Use Hibernate for persistence
4. Configure Hibernate through Spring and use the Hibernate ORM support in Spring to further speed up development and decrease code (both Java AND xml)

Hibernate vs. JDO vs. EJB

[prakslash]

What is the latest on this battle?

There are so many soundbites floating around:

Hibernate is JDOish but does not follow Sun JDO Spec. But.. Gavin King of Hibernate became a member of JD02.0 Expert Group and would make it compatible with JDO 2.0 Spec.

JBOSS is adopting Hibernate as the underlying persistence mechanism for its Container-Managed Entity Java Beans.

EJB 3.0 rejected JDO 2.0.

So.. now I am confused. Who is the winner? Should I buy the book or not? Anyone care to enlighten us?

Re:Hibernate vs. JDO vs. EJB

[koreth]

Hibernate does not really compete with CMP Entity beans, but perhaps sessions beans.

I disagree -- Hibernate is almost a drop-in replacement for CMP entity beans. It does nothing to address the issues that session beans address (implicit transaction management and transparent load balancing, to name the two big things session beans buy you) and does the important thing CMP entity beans do (O-R mapping and removing the need for an object to have code to load and save itself.)

Hibernate does not require you to communicate to another server (RMI, Corba etc).

Neither does EJB, especially as of EJB 2.0. Using local bean interfaces means no RMI overhead -- they're so against you using remote invocations that local bean methods are forbidden from throwing RemoteException!

Not, mind you, that I'm any big fan of CMP entity beans. Using them was the biggest architectural mistake I made when I was starting out in J2EE development. Lots of development overhead, bad performance, and very little real gain. Hibernate beats CMP entity beans in just about every respect.

Re:Not Interested

[espressojim]

High performance? I'm curious, as I'm heavily thinking about shifting from handwritten SQL and the Spring framework to hibernate. I do scientific research, and pull large data sets (.1 - 5M rows) out of a database to operate on.

Often, without carefully tuning these querries, I'm getting horrible performance. With well tuned querries (and appropriate indexing), performace is acceptable. If hibernate was smart enough to say - build anonymous views then join on them when it was a benefit to performance - then I'd be interested. If hibernate was smart enough to aggregate multiple rows of data down to a single row to map onto my summary data objects, I'd be interested. If I'm simply pushing the problem off to another framework, then I'm not sure if it buys me anything over my current methodology.

So, how well does hibernate handle the really complex query work?