- LazyInitializationExceptions
—————————————
Other ORM’s including Ebean ORM don’t throw a LazyInitializationExceptions. That’s a Hibernate specific approach.

- The management of Sessions …
——————————————–
Some ORM’s are design/architected to be “session less”.

Ebean ORM for example doesn’t have an object equivilent to the Hibernate session or JPA EntityManager. Another way of saying this is that Ebean ORM provides “automatic management of the persistence context” – which is what you seemed to alude to.

As you probably know, the point of that is to remove the need to manage the “session” objects which makes life easier much for the developer.

Aka ORM session objects (like Hibernate Session / JPA EntityManager) are an architectural design decision and not required/used by some existing ORM’s today.

- ORMs will monitor how they are used for a certain application, and will use that information to improve the SQL used.
——————————————————–
“Autofetch” defines exactly this behaviour. The application is profiled and from this information the ORM can automatically tune the queries fetching only the properties required.

Ebean ORM has had this feature for about 1 1/2 years. Works very nicely with Ebean’s “partial object” support (which is mostly absent from JPA).

Refer to:
http://www.cs.utexas.edu/~aibrahim/autofetch/
http://www.avaje.org/autofetch.html

A couple of comments to various points:

- I know how to get hibernate the Eager/Lazy loading I need. What I complain about is that in doing so, I annotate domain model with stuff that really belongs in the persistence layer.

- Lazy Initialization Exception: You are probably right about the frameworks. I used Hibernate in a two tier application. Session handling is much less explored in this case

- I don’t think persistence annotations on domain classes are a ‘subjective’ matter. But I do agree that they are better then XML. And I only have a rough idea, how it could be done in a cleaner way.

- I looked at some of the simpler frameworks like ibatis. Its not a direction I want to go.

And since I get the feeling at some got it the other way round: I do like hibernate and will probably use it in the next projects. But I do see room for improvement. Would be strange otherwise, wouldn’t it?

About the generated SQL, I might be not a DB expert but I’ve learnt a lot from the generated SQL, when you test it out it’s often better than what I would have written. That doesn’t mean it’s approaching perfection, but is far from wrong and much better than the average developer.

I really agree with the conclusion; it’s since 3 years know that I lead succesfull project in which the goal is to create a good domain model first, and then have Hibernate generate an appropriate schema. If the schema doesn’t look right, we go back to the model and see what we are doing wrong. It’s more a kind of feedback/validation than the starting point. So definitely Hibernate is maturing, even if many new features are coming, but most people can’t – or don’t want – get the best out of it.

btw, I’ve experienced ibatis: it might be simple, but far from the usefulness, too much work to get stuff working.

Annotations might not be heaven, but are by far the most practical option available.

- The SQL generated by Hibernate by default is horrible. Huge joins, with hundreds of columns, many unneeded.

I think most of the SQL Hibernate generates is fine. In most of the cases, even if it appears bulky, there is no performance hit when it is actually executed by database. If you feel you’re selecting more columns than you need, maybe you need more fine-grained objects in your domain model. If there are too many joins, you are probably using too much EAGER fetching.

Furthermore, you can use custom (native) SQL and still populate the domain objects, if you feel like it.

- Annotations feel like dirt in your code, and maintaining XML mappings is just painful.

This is extremely subjective. I like having annotations in domain classes, since persistence is a key feature of those objects. You can minimize the amount of them by using proper NamingStrategy, so Hibernate can deduce column, table, foreign key names without you specifying them directly.

And the cost of maintaining XML mappings has been blown way out of proportion. Some of the info contained therein can be deduced either from Java side or from the database, but still, how often do you refactor your domain classes and/or database from the ground up? Someone without prior exposure to Hibernate would think there is some kind of magic involved with mapping files, but, in reality, they are quite readable and editable.

- LazyInitializationExceptions are a pain in the a.. neck.

They are no more pain in the neck than, say, NullPonterExceptions. They simply signify the data you ask has not been loaded from database. What would you expect Hibernate to do. If the data is not there, you can either:

1) make sure you fetch it, before you operate on it
2) leave the session open, so Hibernate will do that for you (say, by means of OpenSessionInViewFilter)

Lastly, I wholeheartedly agree with your last paragraph.

I had the same concerns, however I found a solution. I am using the JPA API but I still keep using xdoclet to automatically generate xml mappings! The downside is that meta data kept in Hibernate proprietary form.