Q&A – Greg Luck, CTO Ehcache at Terracotta talks about javax.cache (JSR 107)
We get the latest developments behind Oracle and Terracotta’s cooperation towards creating a standard API for caches
Greg founded Ehcache in 2003. Upon Terracotta’s acquisition of Ehcache in 2009, he assumed the role as the project’s CTO and has been instrumental in building the technology into an enterprise-class caching solution. Greg is also deeply committed to fostering Ehcache’s loyal open source community and regularly speaks at international conferences and seminars.
Can you explain the idea behind javax.cache and how it fits into the Java ecosystem?
The simple idea behind javax.cache is to have a standard API for caches. A cache is a temporary store of data. Caches are now widely used for performance, scale up, and, with distributed caches, scale out.
The spec requires Java 6 or higher. While it will be included in Java EE 7, it can easily be added to existing Java EE 6 and Spring containers, along with existing Java SE applications.
The javax.cache package, as defined by JSR107, is a complement to JPA. While JPA is about persistence, JSR107 is about temporary storage of objects likely to be reused. With that in mind, we have been ensuring the spec harmonises with approaches taken in JPA 2.0.
Can you give us a few details behind its unique features?
The basic concept is a CacheManager that holds and controls a collection of Caches, which in turn have cache entries. A cache entry has a key and a value.
Functionally, the cache API can be thought of as similar to a Map with the following additional features:
- atomic operations, similar to java.util.ConcurrentMap
- read-through caching
- write-through caching
- cache event listeners
- transactions including all isolation levels
- caching annotations
- generic caches, which hold a defined key and value type
- definition of storage by reference (applicable to on heap caches only) and storage by value
How important do you believe it is to standardize caching for the community?
The Java community has always prized standards. The ability to switch out one implementation for another has always been very important and is one very significant difference between the Java community and .net.
So whenever you have a proliferation of implementations around a set of features, it is natural to want to standardise it. Oracle kicked off the idea of JSR107 originally but didn’t have its own cache until the company acquired Tangosol several years ago. And in 2009 Terracotta acquired Ehcache. As a result, we had two corporations able to fund development of the standard.
How long has this been in development for Java EE 7? Any issues along the way?
We kicked it off properly in March after getting support from JSR342, the expert group doing Java EE 7. They definitely provided the trigger to get things moving.
Things have been going smoothly. A lot of new members have joined the Expert Group. We now have 19 members. As you would expect, we have most of the Java caching vendors. But we also have some corporate members such as Goldman Sachs, Citigroup, and some leading individuals such as Eric Dalquist who pioneered caching annotations.
Obviously, Terracotta and Oracle have teamed up for this project. Has the relationship between the two of you going smoothly?
Sure. Cameron Purdy and I have always had cordial relations. Cameron appointed Yannis Cosmadopoulos, a senior Staff Engineer, to be co-spec lead in his place. Yannis and I have a lot of debates but also socialise too. I have been working out of Oracle’s San Francisco office when I am in town and we always go for lunch. I even get invited to the Friday drinks.
Both Oracle and Terracotta share a willingness to be flexible on the licensing. The reference implementation is Apache 2 as are the TCK tests. The whole TCK will be a custom license with a few variations on the standard TCK license. In particular, it will be free and open source friendly.
A lot of vendors have interest in implementing JSR107. Is there anything that Terracotta’s Ehcache offers that the others don’t, or is it fairly standardized across the board?
The API is standardised, but the capabilities will vary widely by vendor. Also some parts of the API are optional: transactions, store by reference and annotations.
On the capabilities side of things, there is much to differentiate vendors:
- Is the cache standalone or distributed?
- Does it support the optional features?
- What is the performance of the implementation?
- Are tiered cache stores supported?
- Can the cache be made persistent?
- Does the cache support search?
- How much data can be put in a cache? In a JVM? Per cache storage node?
- Does the cache support a rich set of data consistency models (e.g. eventual consistency and strong consistency)?
- Are caches highly available? Are they resilient?
- What frameworks does the cache plug into (e.g. Hibernate, Web Caching, Grails, JRuby, HTTP Sessions)?
- Can distributed caches be operated over the WAN? What modes?
In general, there are two classes of cache implementation: open source ones, which don’t do most of the above, and Enterprise Caches, which support these capabilities to different degrees. Enterprise Ehcache fully supports all of these capabilities.
In addition, Ehcache has been for many years the de facto industry standard. More recently, we have created some breakthrough features. We can store hundreds of GBs in each cache node all in memory with our BigMemory technology. We provide the ability to search caches. And in our most recent release, we dramatically simplified our configuration with Automatic Resource Control, which allows caches to automatically allocate their heap and off-heap memory usage.
You recently spoke about the entire project with Cameron Purdy at JavaOne – what reception did you receive from the people at the conference and did they offer any feedback at all?
The session was full. There was and is a lot of interest in JSR107. I think people liked what they saw, but most people outside the expert group still want to take a close look at it.
As a sign of the level of interest, I just gave an updated talk on JSR107 at Devoxx last week and will be giving another talk at Jfokus in February. I plan to show off Ehcache 3.0, which will provide a native implementation of the spec.
How close are we to seeing JSR107 finished?
I think we are close. Yannis and I finished up the baseline spec about a month ago, and it is now getting revised based on review comments. Both Oracle and Terracotta are working on implementations, which is further driving fine-tuning of the spec.
My hope is that we will get a complete JCP first draft done by end of year.
What are Terracotta’s plans for the future, in relation to JSR107?
We will have two implementations. The first is a wrapper, which will work with the current Ehcache 2.5 release. It is in beta now and implements all features other than transactions. (Ehcache supports READ_COMMITTED XA and Local transactions, but under the spec you must provide all isolation modes if you claim transaction support.)
Secondly, the next major version of Ehcache will plan to natively support the API. By this I mean that we will have a Cache class, which will both implement javax.cache.Cache and will also interact with our code in the most efficient way possible. We will likely also continue to support the existing Ehcache API for backward compatibility.
We plan to get this done early next year and be first to market.