Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support for cache2k caching [SPR-16501] #21044

Closed
spring-projects-issues opened this issue Feb 15, 2018 · 9 comments
Closed

Support for cache2k caching [SPR-16501] #21044

spring-projects-issues opened this issue Feb 15, 2018 · 9 comments
Assignees
Labels
in: core status: declined type: enhancement

Comments

@spring-projects-issues
Copy link
Collaborator

@spring-projects-issues spring-projects-issues commented Feb 15, 2018

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
Copy link
Collaborator Author

@spring-projects-issues spring-projects-issues commented Feb 16, 2018

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
Copy link
Collaborator Author

@spring-projects-issues spring-projects-issues commented Feb 19, 2018

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
Copy link
Collaborator Author

@spring-projects-issues spring-projects-issues commented Apr 25, 2018

Stéphane Nicoll commented

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

@spring-projects-issues
Copy link
Collaborator Author

@spring-projects-issues spring-projects-issues commented Jul 3, 2018

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
Copy link
Collaborator Author

@spring-projects-issues spring-projects-issues commented Jul 9, 2018

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
Copy link
Collaborator Author

@spring-projects-issues spring-projects-issues commented Jul 10, 2018

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
Copy link
Collaborator Author

@spring-projects-issues spring-projects-issues commented Jul 10, 2018

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
Copy link
Collaborator Author

@spring-projects-issues spring-projects-issues commented Jul 12, 2018

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
Copy link
Collaborator Author

@spring-projects-issues spring-projects-issues commented Jul 12, 2018

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.

@spring-projects-issues spring-projects-issues added status: declined type: enhancement in: core labels Jan 11, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
in: core status: declined type: enhancement
Projects
None yet
Development

No branches or pull requests

2 participants