On 15 March 2018 at 13:04, Steve Ebersole <steve(a)hibernate.org> wrote:
Given the changes to the second-level cache SPI, I wonder if we want
to
take that as an opportunity to consider dropping the `hibernate-ehcache`
module?
There are a few reasons I am considering this...
1. We have the JCache integration in place and users can use Ehcache
via that support already.
2. This is really the same discussion we had wrt Spring Cache[1]. IMO
the answer should be consistent. We moved hibernate-infinispan for many of
these same reasons...
3. A large part of the argument for keeping hibernate-ehcache was that
it is already in place and therefore did not require much effort to
support/maintain. However, given the new SPI there is actually a pretty
big effort to adapt hibernate-ehcache to those new SPIs. So far I am the
one doing that - which in and of itself is fine since I am the one who
changed the SPIs ;) But it makes me think it is far less of a maintenance
effort just to drop it and support just hibernate-ehcache.
I guess you meant "support just JCache" ?
+1 since the new SPI is different. I do wonder if the JCache API will
be a straitjacket for futher performance improvements, but I guess we
could re-insert this module if there's more concrete elements? At
least any work due to SPI changes could be deferred.
We'll still be testing with Ehcache - over JCache - I hope?
Thanks,
Sanne
WDYT?
[1]
https://github.com/hibernate/hibernate-orm/pull/1639
_______________________________________________
hibernate-dev mailing list
hibernate-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev