Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ


Choose your language

InfoQ Homepage News JSR-107, JCache: Alive and Going to be Part of Java EE 7

JSR-107, JCache: Alive and Going to be Part of Java EE 7

Distributed caching is the tip of the spear for performance and scalability, yet Java does not have a completed standard caching mechanism yet. JSR-107, the JCache API, is being actively worked on and will be included in Java EE 7. JSR-107 has gained some notoriety over the years because it is one of the older JSRs yet has never been completed, but given the increased demand for caching, JSR-107 will finally see the light of day.

InfoQ got a chance to catch up with Greg Luck. Greg is the co-specification lead of JSR-107 and long time commiter and maintainer of Ehcache, a leading open source Java cache implementation.

InfoQ: Is it true that JCache will be part of Java EE 7?

Yes, Java EE 7 (JSR-342) has included JCACHE (JSR-107) as a candidate for inclusion. The JSR-342 spec leads are set up as observers for JSR-107. The JSR-107 spec has a mandatory feature set and two optional features: annotations and JTA. It is this full version we are targeting for inclusion into Java EE 7. We are also closely coordinating with both Linda DeMichiel, the Java EE 7 spec. lead, and the Oracle Java EE 7 team.

InfoQ: Caching seems like an important and missing feature of Java EE and Java, why do you think that JCache took so long?

You can tell from the low spec number of JSR-107 that the idea for the spec was thought of a decade ago. It was originally started by Oracle but then lay dormant for many years. I have been involved for the past 3 years and in the last year, Terracotta and Oracle stepped up to fund JSR-107.

Caching has traditionally been added to enterprise applications after they fail in production rather than planned in the architecture. The one exception has been ORM where the approach itself requires a cache to work.

Greg went on to say that Java EE 7 is targeted at the cloud, and spec leads see the value of including caching. The reasoning: once a developer starts using caching to solve performance issues they see its value. Then developers, endowed with an appreciation for caching, start adding caching to new projects and solutions at the start instead of waiting for performance issues.

This has caused a demand for caching as a recognized part of the architecture not just a performance patch. Greg compared use cases for NoSQL and cache solutions like Ehcache which in many respects try to solve the same problems of scale, but take different approaches. There is also a sharp increase in use of both Ehcahe and memcached in Java and caching in the industry as a whole . Memcached, for example, is a fault resistant distributed cache that went from relative obscurity in 2007 to surpassing the number one commercial distributed cache leader (Oracle Coherence, which also increased) in mind share demonstrating the pent of demand. 

Terracotta, where Greg works, has begun implementing the specification in Ehcache, which will include features like BigMemory, Cache Resource Reservation and will work in standalone mode as well as distributed mode. Ehcache is a well known open source Java cache, especially, if one has a background with using Hibernate.

Ehcache, like most Java cache implementations, has a local in-memory replication mode which provides some significant performance advantages over a purely distributed version. While Memcached stoked interest and demand for caching solutions, faster, standards compliant implementations will likely have a place at the table as well. With a standard API, the argument goes vendors and open source implementations can compete on performance, ease of use, cloud elasticity support, scalability and more.

There are many vendors currently implementing or planning on implementing JCache including Terracotta, Oracle Coherence, JBoss, Caucho's Resin, IBM, Google App Engine and others as caching seems to be more and more a given component of enterprise and cloud solutions.

There seemed to be some controversy around JSR-107 versus JSR-347 a few months back. JSR-347 is the Data Grid JSR.

InfoQ: What if any overlap does JSR-107 have with JSR-347? Where does JSR-107 stop and where does JSR-347 start?

JSR-347 is defined as a superset of JSR-107 (it has a dependency on JSR-107) that adds additional Data Grid features. JSR-107 is being carefully designed to work very well for both standalone caches and distributed caches irrespective of the topology for implementation of the distributed cache. With JSR-107 nearing completion we expect that this will help JSR-347 to define itself.

JSR-347 focuses more energy on defining a robust asynchronous, non-blocking API which is important for data grids. JSR-347 will add additional APIs and support to JSR-107 APIs.

InfoQ: Is JSR-107 only focused on Java EE or is there a Java SE focus as well?

JCache is targeted for Java EE but this does not preclude its use with Java SE. Implementations like Ehcache will be runnable from Java SE, Java EE and Spring.

The API splits into two pieces: a basic profile with no dependencies which can be used from SE and a full profile which adds JTA and caching method annotations. This full version is targeted at Java EE 6, Spring and other enterprise environments. It will work with existing enterprise environments. By being pulled into Java EE 7, it will just be there and hence front of mind for Java developers. We expect the JSR 166 group will build a simple, in-process cache for JDK8.

InfoQ: What major changes and advancements have been made in the progress, process, and/or design of JCache?

We have built the API, RI (Reference Implementation) and TCK (Technology Compatbility Kit) and are publishing them to All source code is up on GitHub. See the Github readme for a full introduction and links. The process is wide open with the spec, the source and the communications all in the open.

From a design point of view, the basic components are a CacheManager that holds and controls collections of Caches. Caches have entries. We have a map like API interface with additions for:

  1. atomic operations
  2. read through caching
  3. write through caching
  4. cache event listeners
  5. stastitics
  6. transactions
  7. annotations

Caches use generics throughout. While we do not mandate a distributed cache topology we have paid careful attention to distributed caches. Both Terracotta and Oracle sell distributed caches and we intend to use this API to be useful to using them.

Developers should find the API simple and powerful and cover a majority of the cases.

JSR-107, by making its mailing list public and specification a public google document, has set some high standards for how open JSRs can be. This alone is a milestone compared to how some JSRs were run in the past.

This specification has been long in coming. It looks like it will finally arrive. Distributed Caching is the tip of the spear for performance and scalability so its good that Java is getting a standard AP for caching. There is a lot of pent up demand for distributed caching in the Java world and JSR-107 will most likely be a welcome addition to the Java landscape.

Rate this Article