The API, though I am not a fan of the RI for one reason. It is the first JSR RI that I am aware of where the authors advice against using, it is unsupported, and intentionally low quality. All other RIs that I know of were production grade quality to ensure it met user's needs. This one was to pass a specification requirement.
- The API violates many of Josh Bloch's guidances [1], including items in Effective Java.
- Many of its features are incompatible with itself. For example, the AOP support cannot be used with loaders, writers, or listeners.
- The AOP support does not support atomic memoization (dog piling [2]) and can crash if initializing the same cache concurrently.
- The JavaDoc dictates implementation details that matched the lead's product, rather than being open ended to allow alternative algorithmic choices.
- The JSR defines an configuration API that is not suitable for production use and promotes the silent usage of unbounded anonymous caches.
- The interfaces do not attempt to feel natural alongside the Java's Collection Framework nor the direction that the language has been heading. It redefines terms, like "access", in an incompatible way.
- Despite numerous delays in being accepted, the JSR was not modified to take advantage of significant changes in the language (java.time, lambdas, CompletableFuture, etc).
- The TCK is not robust, does not check concurrency, and bugs in it languished.
- Most importantly, writing code using JCache is not enjoyable and it is often not flexible enough to solve most needs.
There are likely many more, but that is a short list that comes to mind in a few minutes.
I should have mentioned that the API flaws breaking with Bloch's advice can be really nasty. I bundled up a bunch of items under that, which might mundane if you don't know of them. Some of the wonderful design choices are,
- Cache.iterator() may return a null entry, despite null key or value is disallowed. This occurs when the cursor points to an entry that no longer exists - hasNext() was true, but the entry disappeared due to removal/eviction/expiration. This is a performance optimization to avoid underlying I/O that leaks to users and violates their assumptions.
- Cache.putAll(map) first invokes CacheWriter.writeAll(list<entry>) prior to storing them. The writer uses an in/out parameter so that if an exception is thrown, the user must remove the successfully written entries first. Then cache must store those successfully written entries before propagating the exception to the caller.
- An amusing bug was that their custom future could not be consumed by multiple threads. It used notify(), not notifyAll(), so only one waiter would wake up. The concerning part was that this existed for a few years due to lack interest in releasing a new version.
- The API violates many of Josh Bloch's guidances [1], including items in Effective Java.
- Many of its features are incompatible with itself. For example, the AOP support cannot be used with loaders, writers, or listeners.
- The AOP support does not support atomic memoization (dog piling [2]) and can crash if initializing the same cache concurrently.
- The JavaDoc dictates implementation details that matched the lead's product, rather than being open ended to allow alternative algorithmic choices.
- The JSR defines an configuration API that is not suitable for production use and promotes the silent usage of unbounded anonymous caches.
- The interfaces do not attempt to feel natural alongside the Java's Collection Framework nor the direction that the language has been heading. It redefines terms, like "access", in an incompatible way.
- Despite numerous delays in being accepted, the JSR was not modified to take advantage of significant changes in the language (java.time, lambdas, CompletableFuture, etc).
- The TCK is not robust, does not check concurrency, and bugs in it languished.
- Most importantly, writing code using JCache is not enjoyable and it is often not flexible enough to solve most needs.
There are likely many more, but that is a short list that comes to mind in a few minutes.
[1] https://www.infoq.com/articles/API-Design-Joshua-Bloch
[2] https://en.wikipedia.org/wiki/Cache_stampede