Greetings,

I recently read the following article on SD Times and was very disappointed by the author's lack of knowledge on the subject matter:

http://sdtimes.com/cols/javawatch.htm

I couldn't help but send a response to Mr. Holub, as I feel he really missed the mark with some of his statements. The following is an outline from the email I sent regarding some of the fallacies in the article:

1) "Hibernate's documentation is marginal"

Hibernate has some of the most extensive documentation of any open-source project I've dealt with. FAQs, tuning tips, mailing lists, forums, even the documentation and JavaDocs themselves are quite thorough. Gavin King, the founder of the Hibernate project, is definitely a proponent for comprehensive documentation, which can further be seen by the Manning Hibernate In Action book he and fellow Hibernate developer Christian Bauer are releasing this summer.

2) "The main strength of Hibernate is its ease of use. Object persistence is accomplished using runtime analysis (via the introspection APIs), so there are no special base classes to extend, no post-processor to run, no hassle. You just open an object that represents the persistent store, and then pass it the object that you want to store."

Actually, Hibernate uses runtime reflection and code generation (CGLIB for runtime bytecode generation). I'm not quite sure what Mr. Holub is referring to when he addresses Hibernate's use of introspection; Hibernate CAN use introspection to access the properties of a persisted object. However, it is certainly not the main approach Hibernate uses to implement transparent persistence.

3) "As is the case with all the do-everything-for-you systems, the price you pay for all this power is a less-than-optimal use of the database itself."

This is a pretty vague statement...not sure what Mr. Holub is referring to here, but it would seem like he is addressing Hibernate's generation of sql and database objects. This is a very subjective issue, and thus I will not attempt to refute this point; however, it would have been nice to see a few examples.

4) " As a designer, my main complaint about Hibernate is its use of the get/set idiom to tag the fields that need to be stored. Fortunately, Hibernate uses introspection rather than Java interfaces, so you can (and in fact, should) make the getters and setters private; I strongly recommend that you adopt a style guide that requires them to be private."

Hibernate does not force you to use the get/set idiom to tag persisted fields. In fact, you have a few options here, including both direct accessing of properties and the get/set idiom, as well as your own custom solution (via implementation of the net.sf.hibernate.property.PropertyAccessor interface).


Please let me know if I missed the boat on any of these. I do feel that Hibernate (and JDO) were somewhat misrepresented, and if you agree, you might also want to consider responding.

Thanks,
Scott
http://sourceforge.net/projects/estivate (coming soon)

Yeah, actually it wasn't an especially accurate article. The author doesn't know much about ORM. Still, it was overall favorable, so I'm not upset.

(By the way, he is correct that Hibernate always uses initialization-time introspection, which is not quite the same thing as runtime reflection.)