Hi,
I wonder whether the spec should address (or even encourage?) mixing declarative & imperative access to caches.
Currently the spec. defines caching annotations. As a user I can supply my own (cache) key generator strategy, but a generated key has to implemented
GeneratedCacheKey->
if I want to access to same cache imperatively then I have to either wrap my business keys inside objects implementing the GeneratedCacheKey or pollute business objects with JCache specific code.
I tried use the MicroProfile Demo application as a guinea pig:
The application (imperatively) stores data into JCache and uses `Long` as a cache key. I wanted to use the @CacheRemove annotation to invalidate entries from this cache.
It is possible but it does not feel very good:
1. The spec does not define a default implementation CacheKeyGenerator. It's up to a container to provide one -> When I want to access the same cache imperatively then I always have to implement a custom strategy (or rely on a container-specific implementation)
2. Custom strategies are somewhat
awkward to implement. There is so much boilerplate when all I want to do is to use a specific method argument to calculate a cache key. The
CacheKeyGenerator code feels too low-level for what it does. Spring uses its Expression Language to select keys - that makes it much easier to use.
Now this exercise leads to these questions:
1. Why the CacheKeyGenerator has to return GeneratedCacheKey? Would be object enough? If the Cache interface does not force all keys to implement a specific interface why the CacheKeyGenerator should? Is it possible to relax the CacheKeyGenerator contract?
3. This is probably the most important question: Does the EG want to encourage mixing imperative and declarative approach at all?
Cheers,
Jaromir