Support for cache2k caching [SPR-16501]

[spring-projects-issues]

Jens Wilke opened SPR-16501 and commented

cache2k is one of the best performing Java caches with a hit rate efficiency similar to Caffeine.

The jar size of cache2k is smaller than the currently available alternatives like EHCache and Caffeine. Although its small jar size it comes with XML configuration and JMX support.

The direct support of cache2k makes use of the build in null value support which leads to less overhead than Caffeine or using the JCache API.

---

Referenced from: pull request #1687

[spring-projects-issues]

Stéphane Nicoll commented

Jens Wilke this is interesting. I am puzzled as why you need so much modules for something that claims to be small (400kb)? I really dislike the "project-all" arrangement because build systems don't play nicely with this: if you have use of the individual modules mixed with the use of the "all" jar, you get code duplication on the classpath.

I know this would be a problem to integrate this with Spring Boot which would be the next logical step if we accept this contribution. What do you think?

[spring-projects-issues]

Jens Wilke commented

Stéphane Nicoll, thanks for looking into this. The many individual modules are there to be a better fit for Android. For example, in the targeted Android version, there is no JMX. Nobody but Android users, should use the individual modules instead of cache2k-all, so I consider a problem with the classpath quite small. However, your concern is still relevant.

An alternative approach to cater the Android world would be to deliver a jar with all features, but provide Proguard rules that strip unused "server-stuff" away. I will take a look into this.

Still, I would like to keep the API in a separate jar. Right now the API is also included in the cache2k-all jar, which means only one jar is needed at runtime. To remove the duplication in this case, two jars will be needed in the future, let's say cache2k-api and cache2k-impl.

Ticket for the jar packaging changes: cache2k/cache2k#80

Thoughts?

[spring-projects-issues]

Stéphane Nicoll commented

Let's resume this when there is some progress on that repackaging issue.

[spring-projects-issues]

Jens Wilke commented

Sorry for the long silence. Now I am blessed to have time to get back to this.

Meanwhile I released a preview version that has the new jar file structure. I expect that the final version is ready in a couple of weeks.

I updated the PR to contain the new dependencies. Also improved the cache access performance via the use of Cache.getSimpleEntry().

[spring-projects-issues]

Stéphane Nicoll commented

Thanks a lot Jens, that's interesting. I'll do my best to catch up with this even though it is probably too late for 5.1 now (with RC1 coming up next week).

[spring-projects-issues]

Jens Wilke commented

Thanks for the heads up, Stéphane.

I will push back some other features then and do more testing instead and work towards having a stable and well tested version next week.
Concentrating on the modified packaging is the most important thing right now.

Hopefully, the two jar files approach is okay with you. I know it is rather untypical for a library, but actually I believe there are benefits and others could/should adopt this approach as well. See my comments to your question in cache2k/cache2k#80

[spring-projects-issues]

Stéphane Nicoll commented

I had a chat with Juergen Hoeller yesterday about this one and we came to the conclusion we prefer the Spring integration to be part of cache2k (or a separate project although our preference goes with the former).

There are two main reasons for this:

1. As cache2k is compliant with JCache, there is already an integration via JCache in both Spring Boot and the framework. Also, the surface area of our abstraction is fully covered by our JCache adapter already
2. We are not keen to extend further the adapters we offer in the core.

Would you mind moving that code to a module in cache2k perhaps? If you point me to the commit, I am happy to look at it and review if if you want me to.

Thanks for the support so far, I think the new package structure is great!

[spring-projects-issues]

Jens Wilke commented

Okay, thanks for considering this. Unfortunately JCache is less efficient than the native API and we will loose features that will be valuable for Spring users.
I'll go ahead and provide a separate Spring integration and do some validation with JCache and Spring Boot.
Further comments and discussions can go to: cache2k/cache2k#18

[spring-projects-issues]

Stéphane Nicoll commented

I saw the comment on the PR but Spring users aren't going to lose any feature if you provide a native integration for it.

Said differently, I don't think having it in the core is an absolute requirement, a separate module in cache2k itself is perfectly fine IMO. Once this is in place, we can consider auto-configuring it in Spring Boot.