Support for Hibernate ORM 5.3 [SPR-16303]

[spring-projects-issues]

Juergen Hoeller opened SPR-16303 and commented

Hibernate ORM 5.3 is currently in preparation, finally supporting JPA 2.2. Let's pick it up for our Spring Framework 5.1 release for some deeper integration (e.g. #20852), while continuing Hibernate ORM 5.0-5.2 support at runtime (not least of it all for compatibility with WildFly 10/11 and JBoss EAP 7.0/7.1).

---

Issue Links:

• Support Hibernate 5.3's ManagedBeanRegistry for dependency injection [SPR-16305] #20852 Support Hibernate 5.3's ManagedBeanRegistry for dependency injection ("depends on")
• Upgrade to Hibernate ORM 5.4 [SPR-17517] #22049 Upgrade to Hibernate ORM 5.4 ("is depended on by")
• Support for Hibernate ORM 5.2 [SPR-14327] #18899 Support for Hibernate ORM 5.2
• Compatibility with Bean Validation 2.0 and JPA 2.2 [SPR-13482] #18061 Compatibility with Bean Validation 2.0 and JPA 2.2
• Compatibility with EclipseLink 2.7 [SPR-15870] #20425 Compatibility with EclipseLink 2.7
• Upgrade framework build to JPA 2.2 and JTA 1.3 [SPR-16685] #21226 Upgrade framework build to JPA 2.2 and JTA 1.3
• LocalSessionFactoryBean and HibernateTransactionManager for JPA EntityManagerFactory setup [SPR-17002] #21540 LocalSessionFactoryBean and HibernateTransactionManager for JPA EntityManagerFactory setup
• Deprecate outdated HibernateTemplate operations in favor of lambdas [SPR-16426] #20972 Deprecate outdated HibernateTemplate operations in favor of lambdas
• ClassUtils.getUserClass should support ByteBuddy-generated proxies (e.g. from Hibernate 5.3) [SPR-16569] #21111 ClassUtils.getUserClass should support ByteBuddy-generated proxies (e.g. from Hibernate 5.3)
• Propagate read-only status to Hibernate Session through setDefaultReadOnly [SPR-16956] #21494 Propagate read-only status to Hibernate Session through setDefaultReadOnly

Referenced from: commits e0ccbcb

3 votes, 9 watchers

[spring-projects-issues]

Manuel Dominguez Sarmiento commented

Works needs to be done in HibernateTemplate and possibly other classes due to the following:

Remove support for legacy HQL-style positional parameters
https://hibernate.atlassian.net/browse/HHH-12101

The main issue is that "classic HQL" positional parameters were 0-based, while JPA/JPQL-style ordinal parameters are 1-based.
"Classic HQL" positional parameter support is being removed in Hibernate 5.3.0, while HibernateTemplate is designed to be used with either 0-based positional parameters or named parameters, but apparently there is no support for 1-based ordinal parameters.

Related Hibernate issues:

Deprecate HQL-specific (JDBC-style) positional parameters
https://hibernate.atlassian.net/browse/HHH-7023

Positional parameters report position as name
https://hibernate.atlassian.net/browse/HHH-12116

This can be worked around by exclusively using named parameters (instead of either positional or ordinal), however, some HibernateTemplate methods, such as bulkUpdate() do not currently support named parameters.

[spring-projects-issues]

Juergen Hoeller commented

With respect to HibernateTemplate and in particular the specific data access operations on it, we're primarily keeping that class around for a smooth upgrade path from older Spring-Hibernate applications. For new application setups, we highly recommend direct Hibernate Session usage via SessionFactory.getCurrentSession() or - on Java 8 - possibly HibernateTemplate.execute usage with a SessionCallback implemented as a nested lambda expression.

As a consequence, for any specific HibernateTemplate operations that turn out to be incompatible with Hibernate 5.3, we'd deprecate them on our end in favor of HibernateTemplate.execute usage as outlined above. We are not aiming for completeness of those operations in any case; quite on the contrary, we'd rather reduce them to common conveniences. bulkUpdate seems to be a fine case for such replacement with execute and a Session-based lambda.

[spring-projects-issues]

Manuel Dominguez Sarmiento commented

I understand. However the main issue is that deprecation will not suffice. Code that works in Spring 5.0 + Hibernate 5.2 will cease to work at all when migrating to Spring 5.1 + Hibernate 5.3. We have a very significant codebase we need to maintain (as I'm sure it happens with many other projects that have extensively made use of HibernateTemplate over the years) and it would be useful for the code to continue working without massive recoding.

HibernateTemplate could detect whether the HQL query contains either positional (0-based, "?" style) or ordinal (1-based, "?1" style) parameters. Simple regex parsing can do this easily (no need for complex grammar analysis). Based on this, calls to Query.setParameter(index, value) and similar methods could add 1 to the parameter index if necessary. This should also be backward compatible with Hibernate 5.2 since ordinal ?1 style parameters have been supported for many years now, since Hibernate increasingly aligned with the standard JPA spec.

I agree that HibernateTemplate should probably be deprecated going forward, but a minor release (either Spring or Hibernate) should not stop solid ORM code from working, at least not without some clear and simple upgrade path.

[spring-projects-issues]

Juergen Hoeller commented

I'm afraid we won't be going to the extent of analyzing and/or manipulating user-specified HQL queries, not even for 'simple' regex replacements. This is potentially a deep hole in terms of follow-up bugs and a line that we never crossed before. We can keep existing HibernateTemplate code working as long as the underlying Hibernate version supports it... but as far as I'm concerned, we won't be extending our semi-deprecated HibernateTemplate to a new positional parameter style at this late point.

Fundamentally, the outright removal of the legacy HQL positional parameter style is an aggressive step for a minor release in Hibernate itself. I suppose this means that legacy "?" placeholders won't work at all anymore? So it's not just about adapting the parameter index in Query.setParameter calls, it's also about redefining the queries with "?1" style parameters? Since this is equally true for native Session based code and HibernateTemplate based code, I don't see why this should be worked around on our end.

Frankly, I'd rather recommend continued use of Hibernate ORM 5.2.x with Spring Framework 5.1. We'll keep supporting Hibernate ORM 5.0-5.3 at runtime anyway, so we'll allow for selective upgrading to Spring Framework 5.x while keeping your existing Hibernate version.

[spring-projects-issues]

Juergen Hoeller commented

Our build is upgraded to Hibernate ORM 5.3 final now; everything looks fine so far. Deeper integration with its new SPIs is still pending.