Hi Emmanuel - yeah there are a few notable differences in ehcache 3.x - I’m about halfway through getting everything to compile. The notable differences I’ve found are:
1 - the Cache object now uses generics i.e. Cache<K,V> - the put methods no longer use an Entry object but take K,V directly 2 - the configuration methods do more of the work but expose fewer of the properties programmatically - notably there are places where the current code updates the cache configurations after initialization, which I believe probably isn’t needed anyway but nonetheless doesn’t seem to be supported in v3 Caffeine says it has a JSR-107 wrapper - will you implement Caffeine directly or via JSR-107? I’ll submit a pull request soon anyway so you can see the changes I made to support ehcache v3 and decide if you want to keep them or not. Thanks! Best regards, Richard > On Dec 23, 2018, at 11:13 PM, Emmanuel Lécharny <[email protected]> wrote: > > > On 23/12/2018 21:16, Stefan Seelmann wrote: >> Hi Richard, >> >> I don't think it is planned. > > What I expect to do is to get rid of ehcache completely in favor of Caffeine > (https://github.com/ben-manes/caffeine). > > I did some tests a few months ago, and I can say it's lightweight compared to > ehcache, and more efficient. > > Regarding a move to ehcache 3.0, IFAIR, the API change a bit. ATM, the trunk > is using ehcache 2.10.4.
