Submitted by Ben Cotton (not verified) on Wed, 2010-09-01 17:02.
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.
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.