We\'re in the process of planning a large, enterprise application. We\'re focusing our efforts on evaluating hibernate after experiencing the pains of J2EE.
It looks
Be aware that using JPA/Hibernate (and probably most other ORM solutions) in non-trivial multi-threaded applications can quickly become a real PITA because database sessions need to be confined to exactly one thread (Session objects are not thread-safe). Add lazy loading and the fact that persistent entities can belong to at most one active session...and you're in for a hell of a ride...
You might want to have a look at Session management using Hibernate in a *multi-threaded* Swing application (or just search for 'hibernate multi-threaded').
My rule of thumb (YMMV): If the application does not lend itself to some kind of request/response cycle (like a webservice for example) , you may probably be better off using something else.
Of course, another solution would be to design the application in a way that circumvents the mentioned framework limitations. Changing an application's design so I can get framework XYZ to work leaves a bad aftertaste though.
Anyway, just my $0.02