» What happened to JCache, aka JSR-107?

What happened to JCache, aka JSR-107?

Posted on 10 September 2009 - 16:17

Looking around for Java cache systems, I found that a lot of them claim to be JSR-107 compliant. Now this JSR never went past the review ballot in 2001, and the latest available draft is from 2005.

Among the products that claim compliance, some of them are "serious" ones and I'm surprised that they're happy with a dormant draft specification:

But many of them implement their variant or repackaging of the spec, requiring developers to define their own interfaces to shield the application from these naming variations.

So what happened to this JSR? In these times where memcached is king but memory grids (aka distributed caches) are probably more suited to Java servers, why has it stalled?

Anonymous's picture


I was just looking for information on this Cache JSR and it looks really old: no generics, no annotations, no support for injecting cached values into objects, seems like it needs to be re-worked for the current times?

For the time being, I will continue to use OSCache as a cache provider: very easy to use, easy to configure with the Spring framework, and pretty much stable: it fullfills all my (humble) needs.


Anonymous's picture

I was on the original JSR 107. Oracle was the 'sponsor' of it. Nobody in the JSR wanted to work for Oracle for free and the JSR just never went anywhere. Brian Goetz and some others eventually started working on the API regardless of Oracle. Eventually Oracle dropped out of the JSR and someone else took over. That was like 8-9 years ago I think. That said, it is kind of a dead JSR simply because nobody has picked it up.

I'm currently switching my apps from jboss cache 1.x to ehcache. It is much faster, better statistics and generally just works fine. The API is a bit clunky (why isn't there a cache.put(Object, Object)?, but it works well enough.

Anonymous's picture

JSR-107 is very much in need of a revival. Speaking for our deployments, the Caching tier is now *the* center piece technology. There are a growing number of caching providers, each with their specific points of merit and capability. From the application developer perspective we *need* a Java Caching Connectivity API standard ... ie we need JSR-107. As it exists now we cannot separate our business caching operators and our business caching operands to be provider (vendor) independent. The burden for building a provider independent caching wrapper API is on us. That is not the way it should be. The caching vendors need to get together and get JSR-107. They need to definitely update the old draft to mandate generics, annotations, etc. They need to co-operate on the API and compete on their implementation. They need to do it today.

Anonymous's picture