Encountering a java.lang.NoClassDefFoundError can be one of the most frustrating issues when working with Java applications. This particular error — org/hibernate/cache/CacheProvider — is a common stumbling block for developers upgrading or mixing Hibernate versions. Let’s break down what it means and how to fix it.
Understanding the Error
The NoClassDefFoundError occurs when the JVM tries to load a class by its fully qualified name but cannot find its definition at runtime — even though the class existed at compile time. In this case, org.hibernate.cache.CacheProvider was the standard interface for Hibernate second-level cache integration in Hibernate 3.x. It was deprecated in Hibernate 4 and completely removed in Hibernate 5+, replaced by org.hibernate.cache.spi.RegionFactory.
Which Hibernate Version Are You Actually On?
This error has a different root cause depending on which Hibernate version you’re running. Find your version below and jump straight to the fix that applies to you:
| Hibernate Version | Why You’re Seeing This Error | What To Do |
|---|---|---|
| 3.x | CacheProvider is present but you may be missing the caching JAR on the classpath, or mixing incompatible Ehcache versions. | Migrate to RegionFactory, the cache abstraction that replaced CacheProvider in this era. See Solution 1 below for the modern equivalent, or Solution 2 for a quick unblock. |
| 4.x / 5.x | The CacheProvider API is already gone in these versions. A legacy Ehcache 2.x JAR (built for Hibernate 3.x) is on your classpath. | Check your hibernate-jcache (or equivalent second-level cache provider) setup instead of looking for CacheProvider — see Solution 1. |
| 6.x | Same legacy-Ehcache-2.x classpath conflict, now against the Jakarta namespace. | Use the JCache bridge with the jakarta classifier — see Solution 1 and the Hibernate 6 L2 Caching guide. |
| 7.x | Same conflict; Hibernate 7 requires hibernate-jcache:7.0.1.Final with Ehcache 3. | Use the exact dependency and config shown in Solution 1 below. |
In every version from 4.x onward, the fix is the same dependency and configuration swap — only the framing differs. If you’re still on Hibernate 3.x and have a real reason to delay migration, Solution 2 gives you a way to unblock the error without the data implications of mismatched caching.
Root Causes
- Version mismatch: Using an Ehcache 2.x library (designed for Hibernate 3.x) with Hibernate 4, 5, 6, or 7.
- Missing dependency: Using Hibernate 3.x but the caching provider JAR is absent from the runtime classpath.
- Legacy config property: Your config still uses
hibernate.cache.provider_class(Hibernate 3 property) instead ofhibernate.cache.region.factory_class.
Solution 1: Upgrade to the Modern Cache API (Recommended)
For Hibernate 6 and 7, use hibernate-jcache with the ehcache:jakarta classifier. Replace the old hibernate-ehcache dependency entirely:
<dependency>
<groupId>org.hibernate.orm</groupId>
<artifactId>hibernate-jcache</artifactId>
<version>7.0.1.Final</version>
</dependency>
<dependency>
<groupId>org.ehcache</groupId>
<artifactId>ehcache</artifactId>
<version>3.10.8</version>
<classifier>jakarta</classifier>
</dependency>
Update your configuration property:
<!-- Replace old property -->
<!-- hibernate.cache.provider_class=org.hibernate.cache.EhCacheProvider -->
<!-- Use new property -->
<property name="hibernate.cache.region.factory_class">org.hibernate.cache.jcache.internal.JCacheRegionFactory</property>
<property name="hibernate.javax.cache.uri">classpath:ehcache.xml</property>
Solution 2: Disable L2 Cache (Quick Unblock)
If you don’t need the second-level cache, disable it entirely to remove the dependency on any cache provider:
<property name="hibernate.cache.use_second_level_cache">false</property>
<property name="hibernate.cache.use_query_cache">false</property>
Common Pitfalls
- Transitive dependencies: A third-party library may pull in an incompatible old Ehcache version. Run
mvn dependency:treeorgradle dependenciesto find and exclude it. - IDE classpath vs build tool classpath: Your IDE may cache old JARs. Always rebuild from the build tool directly to verify the runtime classpath.
- Server shared libraries: In container deployments (Tomcat, WildFly), conflicting Hibernate JARs in
lib/override your application’s bundled versions. Scope caching JARs correctly.
Frequently Asked Questions
Q1: When was CacheProvider removed from Hibernate?
org.hibernate.cache.CacheProvider was deprecated in Hibernate 4.0 and removed entirely in Hibernate 5.0. If you are seeing this error with Hibernate 5, 6, or 7, it means a legacy caching library designed for Hibernate 3.x is on your classpath.
Q2: What replaces CacheProvider in Hibernate 5+?
org.hibernate.cache.spi.RegionFactory is the modern interface. In Hibernate 6 and 7, the JCache (JSR-107) bridge via hibernate-jcache is the recommended way to plug in Ehcache 3, Caffeine, Hazelcast, or any JCache-compliant provider.
Q3: How do I find which dependency is bringing in the old Ehcache?
Run mvn dependency:tree | grep ehcache (Maven) or gradle dependencies | grep ehcache (Gradle). Identify the transitive source and add an explicit <exclusion> block to remove the incompatible version, then add the correct version explicitly.
Q4: Does this error affect Hibernate 7?
Yes — if you have the old hibernate-ehcache artifact or any Ehcache 2.x JAR on your Hibernate 7 classpath. Hibernate 7 requires the JCache bridge (hibernate-jcache) and Ehcache 3 with the jakarta classifier. Any Ehcache 2.x artifact referencing CacheProvider will trigger this error immediately.
Q5: Can I mix Hibernate 7 with Ehcache 2.x?
No. Ehcache 2.x implements the old CacheProvider / EhCacheRegionFactory API that does not exist in Hibernate 5+. You must migrate to Ehcache 3.x with the JCache bridge. Ehcache 3 is a complete rewrite with a different API and is not backwards compatible with Ehcache 2.x configuration.
Conclusion
This error is almost always a dependency version mismatch between Hibernate and its caching provider. Use the decision table above to identify which version you’re on, then fix it by removing legacy hibernate-ehcache artifacts, switching to hibernate-jcache + Ehcache 3 with the jakarta classifier, and updating the configuration property from provider_class to region.factory_class. If you don’t need L2 caching, simply disable it. Run a dependency tree analysis first — the root cause is nearly always a transitive dependency pulling in an incompatible Ehcache 2.x JAR.
Further Reading & Cross-References
- 📘 Hibernate 7 Second Level Cache — the correct L2 cache setup for Hibernate 7
- 📘 Hibernate 7 Ehcache 3 Configuration — full JCache/Ehcache 3 setup
- 📘 Hibernate 6 L2 Caching with Ehcache 3 — migration from hibernate-ehcache to hibernate-jcache
- 📘 Hibernate 5 to 6 to 7 Migration Guide — the breaking changes and the silent ones
- 🔗 Official Hibernate 7 User Guide — Caching