The most awaited JCACHE also known as JSR 107 – Java Temporary Caching API has finally been released in March 18, 2014. This specification request has been started way back in 2001, nevertheless, over 80% voted for its inclusion in the platform on a 2012 Java EE 7 survey.
In the original proposal posted in the Java Community Process’ website, JCACHE has been described as a specification that standardize process caching of Java objects in a way that allows an efficient implementation, and removes from the programmer the burden of implementing cache expiration, mutual exclusion, spooling, and cache consistency. Objects whose type is not known until runtime can be cached, but only those which implement the serializable interface can be spooled.
The main purpose of JCACHE is to let developers solve usual problems by only writing little code as possible. This will work on any Java platform and will be beneficial to server platforms like servlet container.
It is also said that there are no specifications yet that handle automatic creation and refresh of temporary, in-process data shared across threads. The following are mentioned issues with existing specifications that can be addressed through JCACHE:
Java Naming Directory Interface (JNDI) is used for searching objects by name and an interface for caching implementation. But this application requires checking expiration of retrieved objects after each look up, and synchronizing creation and binding of a new object. Per object cache attributes (e.g., expiration time) would require introduction of an additional level of indirection: the application would look up a cache handle and use one of its methods to access the associated object.
Java.util.Hashtable offers a way of searching objects by name, however, has no way to materialize objects in the cache without application enforcement of expiration and mutual exclusion. HashTable also has no basic spooling capability.
JavaSpaces and Enity Enterprise Java Beans handle caching of persistent, transactional data. Cached data do not always come from data stores; they may be the result of an expensive computation or a remote procedure call. Also, these interfaces do not deal with efficient handling of expiration and refresh of cached data.
Enterprise Java Beans are mainly created for remote access to objects. Although an in-process implementation of EJB is possible, the application code would still have to make all of the additional calls required for remote object access. EJB’s must be pre-defined by the application, and do not have any concept of shared access or expiration.
javax.servlet.http.HttpSession permits named objects of arbitrary type to be cached, but does not have the concept of sharing, invalidation, per object expiration, automatic loading, or spooling.
With its release, JCACHE is now available for download and evaluation.