Fix for #2330 causes Spring Data JPA to no longer run on any Hibernate version before 5.4

[AndreasALoew]

Hello Spring Data JPA team,

I hope that you agree with me that the goal of your project is to provide a piece of software that supports any JPA 2 compliant provider, independent of whether it is the latest and greatest release or whether it might still be an older version of e.g. Hibernate.

In our case, due to the fact that we are tied to JBoss EAP 7.4 as the deployment platform, we mandatorily need to use Hibernate 5.3.x (5.3.23.Final-redhat-00001 as of 7.4.1.GA) as the JPA provider.

But it turns out that due to the fix for #2330 (#2330; 87da84b), Spring Data JPA no longer runs on any Hibernate version before 5.4.0, as the Spring Data JPA "org.springframework.data.jpa.provider.PersistenceProvider" for Hibernate, in its method getIdClassAttributes(PersistenceProvider.java:106), tries to access Hibernate class "org.hibernate.metamodel.model.domain.spi.IdentifiableTypeDescriptor" - but this class is only present in Hibernate versions 5.4.0 or newer.

This class has only been introduced into Hibernate ORM by the commit for "HHH-12713 - Make EntityGraph creation more convenient" (hibernate/hibernate-orm@d0fb16d), but is not existing in any Hibernate version before 5.4, which means when trying to use a current Spring Data JPA build (starting from 2.5.6) to access Hibernate version 5.3.x, you will get the following exception:

Caused by: java.lang.NoClassDefFoundError: org/hibernate/metamodel/model/domain/spi/IdentifiableTypeDescriptor
	at deployment.ndm-bnb-adminconsole-0.0.1-SNAPSHOT.war//org.springframework.data.jpa.provider.PersistenceProvider$1.getIdClassAttributes(PersistenceProvider.java:106)
	at deployment.ndm-bnb-adminconsole-0.0.1-SNAPSHOT.war//org.springframework.data.jpa.repository.support.JpaMetamodelEntityInformation$IdMetadata.<init>(JpaMetamodelEntityInformation.java:271)
	at deployment.ndm-bnb-adminconsole-0.0.1-SNAPSHOT.war//org.springframework.data.jpa.repository.support.JpaMetamodelEntityInformation.<init>(JpaMetamodelEntityInformation.java:89)
	at deployment.ndm-bnb-adminconsole-0.0.1-SNAPSHOT.war//org.springframework.data.jpa.repository.support.JpaEntityInformationSupport.getEntityInformation(JpaEntityInformationSupport.java:66)
	at deployment.ndm-bnb-adminconsole-0.0.1-SNAPSHOT.war//org.springframework.data.jpa.repository.support.JpaRepositoryFactory.getEntityInformation(JpaRepositoryFactory.java:232)
	at deployment.ndm-bnb-adminconsole-0.0.1-SNAPSHOT.war//org.springframework.data.jpa.repository.support.JpaRepositoryFactory.getTargetRepository(JpaRepositoryFactory.java:181)
	at deployment.ndm-bnb-adminconsole-0.0.1-SNAPSHOT.war//org.springframework.data.jpa.repository.support.JpaRepositoryFactory.getTargetRepository(JpaRepositoryFactory.java:164)
	at deployment.ndm-bnb-adminconsole-0.0.1-SNAPSHOT.war//org.springframework.data.jpa.repository.support.JpaRepositoryFactory.getTargetRepository(JpaRepositoryFactory.java:75)
	at deployment.ndm-bnb-adminconsole-0.0.1-SNAPSHOT.war//org.springframework.data.repository.core.support.RepositoryFactorySupport.getRepository(RepositoryFactorySupport.java:324)
	at deployment.ndm-bnb-adminconsole-0.0.1-SNAPSHOT.war//org.springframework.data.repository.core.support.RepositoryFactoryBeanSupport.lambda$afterPropertiesSet$5(RepositoryFactoryBeanSupport.java:322)
	at deployment.ndm-bnb-adminconsole-0.0.1-SNAPSHOT.war//org.springframework.data.util.Lazy.getNullable(Lazy.java:230)
	at deployment.ndm-bnb-adminconsole-0.0.1-SNAPSHOT.war//org.springframework.data.util.Lazy.get(Lazy.java:114)
	at deployment.ndm-bnb-adminconsole-0.0.1-SNAPSHOT.war//org.springframework.data.repository.core.support.RepositoryFactoryBeanSupport.afterPropertiesSet(RepositoryFactoryBeanSupport.java:328)
	at deployment.ndm-bnb-adminconsole-0.0.1-SNAPSHOT.war//org.springframework.data.jpa.repository.support.JpaRepositoryFactoryBean.afterPropertiesSet(JpaRepositoryFactoryBean.java:144)
	at deployment.ndm-bnb-adminconsole-0.0.1-SNAPSHOT.war//org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.invokeInitMethods(AbstractAutowireCapableBeanFactory.java:1863)
	at deployment.ndm-bnb-adminconsole-0.0.1-SNAPSHOT.war//org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.initializeBean(AbstractAutowireCapableBeanFactory.java:1800)
	... 53 more
Caused by: java.lang.ClassNotFoundException: org.hibernate.metamodel.model.domain.spi.IdentifiableTypeDescriptor from [Module "deployment.ndm-bnb-adminconsole-0.0.1-SNAPSHOT.war" from Service Module Loader]
	at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:255)
	at org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:410)
	at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:398)
	at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:116)
	... 69 more

Can you please fix the PersistenceProvider implementation to still support older Hibernate releases as well (and fall back to its previous behaviour when it detects a Hibernate version < 5.4 which does not provide the class that it is trying to access)?

Many thanks for listening!
Andreas

[mp911de]

Generally, we guarantee only compatibility for the versions that we compile against. There is a fairly good chance that older or newer versions of implementations work with a particular Spring Data JPA version but there's no guarantee.

A lot of things that we need to do in Spring Data JPA require the use of JPA implementation-specific code because either the JPA specification is interpreted differently by the JPA implementations or particular features are not exposed by the JPA spec itself.

We can certainly investigate what can be done to avoid the hard requirement on IdentifiableTypeDescriptor but we generally do not verify that Spring Data JPA runs on all maintained versions for specific JPA providers.

[AndreasALoew]

Hello Mark,

many thanks for looking into this.

Let me start by explicitly stating that I fully agree with three statements that you made:

(1) "we generally do not verify that Spring Data JPA runs on all maintained versions for specific JPA providers"
It is completely clear that, due to the mere number of different JPA providers, you would never be able to verify this constructively, check this "in advance" by testing.

(2) "a lot of things that we need to do in Spring Data JPA require the use of JPA implementation-specific code"
Unfortunately, this also is very true. I also clearly agree that especially the subtle differences between providers (even the big ones, e.g. comparing Hibernate with TopLink/EclipseLink) can make your job - and that of everybody who needs to support different providers - a hard one.

(3) "we generally do not verify that Spring Data JPA runs on all maintained versions for specific JPA providers"
see (1) - I also clearly do not expect you to explicitly test this - this simply is not feasible either.

But (and here finally comes my "but"... 😉) it should be in the Spring Data JPA project's interest that for the major providers, especially the "big two", you ensure "on demand" (i.e. when issues are raised such as in my case) that in fact not only the most recent release will work fine with Spring Data JPA, but also slightly older ones (which are still widely used in commercial products across the industry). In our case, due to the fact that we also desperately need commercial Infinispan support for Hibernate 2nd level cache, we are unfortunately tied to use the version of Hibernate that our vendor supports, and this currently still is the 5.3.x series (5.3.21 or later) on the most recent JBoss 7.4.x...

This will help to ensure that your wide user base is able to follow you closely and use your latest and greatest releases (Spring Boot as well as Spring Data JPA) even though tied to older versions of the JPA providers.

My proposal would be as follows: Spring Data JPA should try to ensure on a best effort basis that it still runs on "fairly recent" versions of Hibernate as well as TopLink/EclipseLink (and not just the latest). In case someone notifies you about an incompatibility (which is typically introduced through the provider-specific code around class org.springframework.data.jpa.provider.PersistenceProvider), you could detect particular versions with "breaking" API changes and keep the old versions of the version-specific PersistenceProvider code in addition to the new ones for a grace period.
You might also want to explicitly deprecate provider versions that become so outdated that they are no longer used in relevant numbers...

Technically, this could be done either by reflection, by selecting/configuring different Enum instance versions, or by using "other means" to detect provider version for different product versions of Hibernate (here: 5.3 and below, 5.4 and upwards).

Just while I type this, I can already see that some activities happen (a pull request... 😄) - this is great work & listening to your user base!

Thanks a million, Mark, for your kind support! 👍