Deprecate outdated HibernateTemplate operations in favor of lambdas [SPR-16426]

[spring-projects-issues]

Juergen Hoeller opened SPR-16426 and commented

In anticipation of Hibernate ORM 5.3 (#20850) and for example its removal of legacy positional parameters, let's revisit HibernateTemplate and possibly deprecate affected operations upfront, allowing either for removal in Spring Framework 5.1/5.2 or at least for only supporting them against Hibernate ORM 5.0-5.2 but not 5.3.

---

Issue Links:

• Support for Hibernate ORM 5.3 [SPR-16303] #20850 Support for Hibernate ORM 5.3
• Doc: hibernate.dialect_resolvers vs HibernateJpaVendorAdapter.setDatabase [SPR-16428] #20974 Doc: hibernate.dialect_resolvers vs HibernateJpaVendorAdapter.setDatabase

Referenced from: commits 4e194c3

[spring-projects-issues]

Juergen Hoeller commented

I've marked all parameter-based find operations (as well as iterate and bulkUpdate) as deprecated now since they are all better off with the general HibernateTemplate.execute method and a custom lambda expression against the callback-provided Hibernate Session. Such user-specified code blocks can easily choose the right position index style for their queries then or - preferably - conveniently specify named parameters against org.hibernate.query.Query, avoiding the rather awkward inline parameter approach in HibernateTemplate.findByNamedParam, in particular now that we are on Java 8+.

I've also documented that such deprecated operations are known to work against Hibernate ORM 5.0-5.2 but may not work against Hibernate ORM 5.3 anymore (in particular when using positional parameters). We'll keep them around for use of Spring Framework 5.x against Hibernate ORM 5.0-5.2 but won't upgrade them any further. Existing applications are adviced to upgrade to Hibernate ORM 5.2.x for the time being, planning for 5.3 as a larger upgrade where the application's query operations might have to be revisited.