It's complex because the problem is more complex than the existing implementation could adequately address. See http://wiki.jboss.org/wiki/Wiki.jsp?page=JBossCacheHibernateAlignment. Biggest difference is that Hibernate now uses 4 different types of caching regions, with necessarily different semantics for each. The proper integration of each of those region types expands the number of classes in the integration. The Hibernate READ_ONLY caching strategy is also now supported; that adds a few trivial classes. Building the 4 region types from a single shared JBC instance is supported, as is using different JBC instances that use a single underlying multiplexed JGroups channel. That adds a few classes. Arguably the single shared JBC instance approach should be dropped; that's a better discussion for the Hibernate dev list or forums, since it's really a question of what Hibernate wants to provide. Hibernate previously supported more Provider impls than the 2 you mentioned. There were also flavors that used a JNDI lookup instead of direct cache instantiation. Same still applies. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4098019#... Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...