What is the intended upgrade path for legacy Hibernate applications?

Question

I recently had the pleasure of being allowed to bump the version of the Hibernate dependency (amongst others) in a medium sized legacy code base (from 3.x to 5.2). The code itself is partially over 10 years old but still in daily use.

So even after increasing the version and porting as much API calls away from now deprecated or even missing areas to their bleeding edge counterparts (finding out how to do a SchemaExport was a particularly fun experience) I still don't see this as a complete migration.

I'm wondering what the intended upgrade path is for legacy users as often enterprise systems will be around for 10 to 15+ years and still at times you need to jump to a newer dependency version to get necessary bugfixes or features.

The following points are somewhat still open:

• There is no clear or automatic way to migrate .hbm.xml mapping information to JPA annotations. I know a manual migration will be very error prone and not all concepts do have clear or obvious counter parts.

• We now get a lot of deprecation warnings (org.hibernate.orm.deprecation) about our usage of the old Criteria API but there is also no clear upgrade path. One can not just re-write the whole db access code of an application to a completely different and more verbose API that will surely behave different at certain edge cases.

• We seem to use a lot of native queries and instances of org.hibernate.transform.ResultTransformer yet the org.hibernate.query.Query#setResultTransformer() seems to be deprecated with no indication of how to work around this.

In general I find the documentation about deprecation and intended upgrade paths on Hibernate's side a litte scarce. I do understand that it is an Open Source project and that they don't want to maintain old APIs forever but still I'm feeling a little lost and I don't believe this to be the only legacy Java application out there still in use today.

Answer 1

I understand what you mean. In fact, I've been recently seeing all sorts of questions on our forum regarding migration from 3.x to 4.x and 5.x.

1. I think we should have a migration landing page as a starting page for every migration. This way, users will have to go to a single page and find everything they need.
2. We don't have an automatic HBM-to-Annotations tool. However, there is an alternative. You can do HBM -> database, and then use the Reverse Engineer Tool to generate Annotations from your database schema.
3. Legacy Criteria is deprecated since we can no longer afford to maintain two Criteria APIs. Plus, the JPA Criteria is more advanced (it has type safe queries and Metamodel). Unfortunately, there is no automatic migration from legacy to Criteria API either. But then, even if you have hundreds of such method calls, you can easily migrate them either automatically (regex/perl/vi) or manually. It's not going to take that much to do it.
4. The ResultTransformer is going to be substituted with a new mechanism that can better take advantage of lambdas. For this reason, the new interface or interfaces will have to be functional interfaces.