Remove IntCache and LongCache for int and long keys

Remove the IntCache and LongCache interfaces again. Since hotspot does escape analysis an autoboxed Integer is optimized away any way.

Plan:

• Deprecate in 1.x
• Remove in 2.0

[cruftex]

What I had with LongCache and IntCache was only half hearted. Some methods had an int lor long version, others did not. The whole API is too big to make it consistently. I just counted around 30 interface in the API using the type parameters K, V. The whole thing made a terrible mess. When doing it again, maybe with a complete separate and simpler API and then have primitive versions for every method in it consistently.

There is still an optimization present for int keys. When using int keys no object is stored. This did blend in quite well with the existing code base. The cache entry stores the hash code of the key object, identically like the HashMap. When there are only integer keys I use the hash code field directly for the key and do not store the object reference.

performance seems to be the main differentiator of Cache2k from other caching solutions.

Performance is the main selling point of every cache solution. With cache2k I managed to have faster access times than any other Java cache and proved that its possible to minimize the access overhead needed for cache eviction to a minimum while still getting an acceptable eviction efficiency that is mostly better than LRU. I update the https://cache2k.org/benchmarks.html page now with every version.

At the moment, big performance gains can be achieved, simply by using cache2k instead of another cache implementation. More optimization makes sense when there is a larger user base. Only then I can make a power plant superficial 😉

I am not saying that the performance is the best and therefore good enough. Further improvement is always good, however I need to focus and prioritize. That optimization was a big slowdown for the further ongoing development.

But I admit that my explanation in the issue was rather thin. So now we have the longer version. Thanks for asking.

[maxim5]

Thanks!

My hope is that this problem is solved in a generic way via JVM optimizations.

That is my hope as well.

I think it is still good to get simpler.

I agree with this argument. But there’s one nuance: performance seems to be the main differentiator of Cache2k from other caching solutions. Applications looking for best performance are likely to consider primitive keys, and to me that’s the counter-argument to maintain the extra complexity. And it’s surprising to see a feature removed based on a hypothesis that it doesn’t hurt the main “selling point”.

Unless, of course, boxing overhead is not significant in benchmarks, so there’s little reason to go for int or long keys even in performance critical classes.