Crimson and Clover

As part of work to do provide coverage reports for the TCK of JCache we had to add a coverage tool. As we are open source I spent some time playing with coverage tools.

We build with Maven 3. For reasons do with usage of the TCK, we have four standalone modules: jsr107soec, jsr107tck, RI and Demo. Within the jsr107tck and RI there is a parent pom and children with back references to their parents. To easily run the four top level modules we have an aggregate module which is not declared as a parent in the poms of the four top level modules. It looks like this.

<project xmlns=""

An unusual aspect of this arrangements is that all tests for the RI are contained in the jsr107tck module. The RI itself has no tests.

My approach was to spend a few hours with first the open source coverage tools, Emma and Cobertura, and then to move on to Clover which I have used before, if needed.

Emma’s Maven plugin is old and needs a work around for Java 7. But got it basically working but could not get it to deal with our complicated structure.

Then I tried Cobertura. Version 2.6 of the Maven module was released just in August. It worked fine with Java 7. But once again I found it difficult to make progress with our complicated structure. I was thinking the best approach would be to give all modules the same coverage database location. In Cobertura you do this with a system property. e.g. -Dnet.sourceforge.cobertura.datafile=/path/cobertura.ser . I didn’t get this working.

I then tried Clover, and got up and running. I specified the same clover.db location for all modules. I needed to add this to the aggregate pom, and each top level pom. For those top level modules with children, defining it in the parent was sufficient. I added the following to each of those poms.

Then to run a build with clover instrumentation:
mvn clean com.atlassian.maven.plugins:maven-clover2-plugin:setup install

And to run the clover report:
mvn com.atlassian.maven.plugins:maven-clover2-plugin:clover

Note the wordy module definitions. You can use the short name of clover2 if you add the following to your settings.xml:


The first example then becomes:
mvn clean clover2:setup install

It would be great if they could change the User Guide to point out this step as it mars what is otherwise a very smooth experience.

Lambda Hello World

I was recently checking Lambda expressions out to ensure the forthcoming JCache spec would work Ok with them. I just wanted a really simple example that worked through the different syntactical forms and ended up putting a Hello World type example myself.

* Hello world!
public class App {

static void print(Something something) {
System.out.println(something.doSomeThing("Hello World"));

interface Something {

String doSomeThing(String word);

public static void main(String[] args) {
print(new Something() {

public String doSomeThing(String word) {
return word.concat(" - it is no fun to AnonymousInnerClass");

//expression form. No return
print((String s) -> s.concat(" = it is fun to Lambda"));

//block. Need return as interface method has return.
print((String s) -> {return s.concat(" = it is fun to Lambda");});

//expression. No type required as Interface defines it.
print((s) -> s.concat(" = it is fun to Lambda"));

//creating a concrete instance of a functional interface via assignment
Something something = (s) -> s.replace("the", "thee");
System.out.println(something.doSomeThing("What the!"));

java.util.function.Predicate predicate = new


JSR107 JCache enters Public Draft Review

On 5 July 2013, JSR107 went into Public Draft Review and which will last until 4 August.

Visit the JSR home page on GitHub to get the code. Or read the spec.

I encourage anyone interested in Java caching to take a look and give us feedback which you can do by posting an issue on GitHub for specific things or for more general feedback posting to the JSR107 Google Groups mailing list.

JSR107 enters Early Draft Review after nearly 12 years

On 23 October 2012 the JCP posted the Early Draft specification and API for JSR107. See This is almost 12 years since the JSR kicked off. Note that this material was uploaded to the JCP in February this year but was delayed while the legal complications of having two companies as shared spec leads got sorted out. That is now done and will not be an issue going forward in the process.
We will now be working intensively to drive this to completion in its own right and for inclusion in Java ## 7. We expect to be final in early 2013.
We need your review
In the meantime the early draft review period is open until 22 November. Please visit the home of the project at and send your comments to or create issues at For a quick into see
We have also just added a few new artifacts up on GitHub:
- A very simple demo which can be used when giving talks.
- ehcache-jcache – an implementation of the 0.5 specification that works with the latest version of ehcache.
Remaining JCP 2.7 Process Steps
The review period ends 22 November. Once we have a public draft, we will submit that for 30 days’ review. A EC ballot will be held in the last week of the public draft period before we move on to complete the RI and TCK and seek final approval.
Java EE 7 Deadline
We have sought clarification from the EE JSR on their deadline. It is fast approaching. We therefore intend to go hard.

javax.cache: The new Java Caching Standard

This post explores the new Java caching standard: javax.cache.

How it Fits into the Java Ecosystem

This standard is being developed by JSR107, of which the author is co-spec lead. JSR107 is included in Java EE 7, being developed by JSR342. Java EE 7 is due to be finalised at the end of 2012. But in the meantime javax.cache will work in Java SE 6 and higher and Java EE 6 environments as well aswith Spring and other popular environments.

JSR107 has draft status. We are currently at release 0.3 of the API, the reference implementation and the TCK. The code samples in this article work against this version.


Vendors who are either active members of the expert group or have expressed interest in implementing the specification are:

  • Terracotta – Ehcache
  • Oracle – Coherence
  • JBoss – Infinispan
  • IBM – ExtemeScale
  • SpringSource – Gemfire
  • GridGain
  • TMax
  • Google App Engine Java

Terracotta will be releasing a module for Ehcache to coincide with the final draft and then updating that if required for the final version.


From a design point of view, the basic concepts are a CacheManager that holds and controls a collection of Caches. Caches have entries. The basic API can be thought of map-­like with the following additional features:

  • atomic operations, similar to java.util.ConcurrentMap
  • read-through caching
  • write-through caching
  • cache event listeners
  • statistics
  • 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

Optional Features

Rather than split the specification into a number of editions targeted at different user constituencies such as Java SE and Spring/EE, we have taken a different approach.

Firstly, for Java SE style caching there are no dependencies. And for Spring/EE where you might want to use annotations and/or transactions, the dependencies will be satisfied by those frameworks.

Secondly we have a capabilities API via ServiceProvider.isSupported(OptionalFeature feature)so that you can determine at runtime what the capabilities of the implementation are.  Optional features are:

  • storeByReference – storeByValue is the default
  • transactional
  • annotations

This makes it possible for an implementation to support the specification without necessarily supporting all the features, and allows end users and frameworks to discover what the features are so they can dynamically configure appropriate usage.

Good for Standalone and Distributed Caching

While the specification does not mandate a particular distributed cache topology it is cognizant that caches may well be distributed. We have one API that covers both usages but it is sensitive to distributed concerns. For example CacheEntryListener has a NotificationScope of events it listens for so that events can be restricted to local delivery. We do not have high network cost map-like methods such as keySet() and values(). And we generally prefer zero or low cost return types. So while Map has V put(K key, V value) javax.cache.Cache has void put(K key, V value).


Caches contain data shared by multiple threads which may themselves be running in different container applications or OSGi bundles within one JVM and might be distributed across multiple JVMs in a cluster. This makes classloading tricky.

We have addressed this problem. When a CacheManager is created a classloader may be specified. If none is specified the implementation provides a default. Either way object de-serialization will use the CacheManager’s classloader.

This is a big improvement over the approach taken by caches like Ehcache that use a fall-back approach. First the thread’s context classloader is used and it that fails, another classloader is tried. This can be made to work in most scenarios but is a bit hit and miss and varies considerably by implementation.

Getting the Code

The spec is in Maven central. The Maven snippet is:


A Cook’s Tour of the API

Creating a CacheManager

We support the Java 6 java.util.ServiceLoader creational approach. It will automaticaly detect a cache implementation in your classpath. You then create a CacheManager with:

CacheManager cacheManager = Caching.getCacheManager();

which returns a singleton CacheManager called “__default__”. Subsequent calls return the same CacheManager.

CacheManagers can have names and classloaders configured in. e.g.

CacheManager cacheManager = Caching.getCacheManager(“app1”, Thread.currentThread().getContextClassLoader());

Implementations may also support direct creation with new for maximum flexibility:

CacheManager cacheManager = new RICacheManager(“app1”, Thread.currentThread().getContextClassLoader());

Or to do the same thing without adding a compile time dependency on any particular implementation:

String className = "javax.cache.implementation.RIServiceProvider";
Class<ServiceProvider> clazz =(Class<ServiceProvider>)Class.forName(className);
ServiceProvider provider = clazz.newInstance();
return provider.createCacheManager(Thread.currentThread().getContextClassLoader(), "app1");
We expect implementations to have their own well-known configuration files which will be used to configure the CacheManager. The name of the CacheManager can be used to distinguish the configuration file. For ehcache, this will be the familiar ehcache.xml placed at the root of the classpath with a hyphenated prefix for the name of the CacheManager. So, the default CacheManager will simply be ehcache.xml and “myCacheManager” will be app1-ehcache.xml.

Creating a Cache

The API supports programmatic creation of caches. This complements the usual convention of configuring caches declaratively which is left to each vendor.

To programmatically configure a cache named “testCache” which is set for read-through

cacheManager = getCacheManager();
CacheConfiguration cacheConfiguration = cacheManager.createCacheConfiguration()
Cache testCache = cacheManager.createCacheBuilder(“testCache”)

Getting a reference to a Cache

You get caches from the CacheManager. To get a cache called “testCache”:

Cache<Integer, Date> cache = cacheManager.getCache(“testCache”);

Basic Cache Operations

To put to a cache:

Cache<Integer, Date> cache = cacheManager.getCache(cacheName);

Date value1 = new Date();

Integer key = 1;

cache.put(key, value1);


To get from a cache:

Cache<Integer, Date> cache = cacheManager.getCache(cacheName);
Date value2 = cache.get(key);


To remove from a cache:

Cache<Integer, Date> cache = cacheManager.getCache(cacheName);
Integer key = 1;


JSR107 introduces a standardised set of caching annotations, which do method level caching interception on annotated classes running in dependency injection containers. Caching annotations are becoming increasingly popular, starting with Ehcache Annotations for Spring, which then influenced Spring 3’s caching annotations.

The JSR107 annotations cover the most common cache operations including:

  • @CacheResult – use the cache
  • @CachePut – put into the cache
  • @CacheRemoveEntry – remove a single entry from the cache
  • @CacheRemoveAll – remove all entries from the cache

When the required cache name, key and value can be inputed they are not required. See the JavaDoc for the details. To allow greater control, you can specify all these and more. In the following example, the cacheName attribute is specified to be “domainCache”, index is specified as the key and domain as the value.

public class DomainDao {
     public void updateDomain(String domainId, @CacheKeyParam int index,
          @CacheValue Domain domain) {

The reference implementation includes an implementation for both Spring and CDI. CDI is the standardised container driven injection introduced in Java EE 6. The implementation is nicely modularised for reuse, uses an Apache license, and we therefore expect several open source caches to reuse them. While we have not done an implementation for Guice, this could be easily done.

Annotation Example

This example shows how to use annotations to keep a cache in sync with an underlying data structure, in this case a Blog manager, and also how to use the cache to speed up responses, done with @CacheResult

public class BlogManager {
public Blog getBlogEntry(String title) {...}
public void removeBlogEntry(String title) {...}
public void removeAllBlogs() {...}
public void createEntry(@CacheKeyParam String title,
@CacheValue Blog blog) {...}
public Blog getEntryCached(String randomArg,
@CacheKeyParam String title){...}

Wiring Up Spring

For Spring the key is the following config line, which adds the caching annotation interceptors into the Spring context:

<jcache-spring:annotation-driven proxy-target-class="true"/>

A full example  is:

<beans ...>
<jcache-spring:annotation-driven proxy-target-class="true"/>
<bean id="cacheManager" factory-method="getCacheManager" />

Spring has it’s own caching annotations based on earlier work from JSR107 contributor Eric Dalquist. Those annotations and JSR107 will happily co-exist.

Wiring Up CDI

First create an implementation of javax.cache.annotation.BeanProvider and then tell CDI where to find it  declaring a resource named javax.cache.annotation.BeanProvider in the classpath at /META-INF/services/.

For an example using the Weld implementation of CDI, see the CdiBeanProvider in our CDI test harness.

Further Reading

For further reading visit the JSRs home page at

0.3 of JSR107:javax.cache released

0.3 of the JSR107 spec, RI and TCK have been released.

Changes in this release:

  • Numerous changes across the spec, TCK and RI
  • Annotations implementations in the RI for Spring and CDI
  • Transactions API finalised
The release is in Maven central so the snippet for the API is:

We are pretty much on the home run with this now. Work on Ehcache, Infinispan and Coherence implementations are starting. Work will now shift to closing open issues and dealing with review comments as they come in.

We welcome community involvement. The jumping off point for all things JSR107 is the GitHub Page.

Start using JSR107′s JCache API

JCache is rapidly nearing completion and we would like the community to start using it. The API is becoming quite stable.

The home for all things JCache is: Today I updated that page with the following details so that you can all get started.

We expect to release our first non-snapshot release in a few week’s time with further releases leading up to JavaOne.

I am doing two sessions on caching at JavaOne. If you are attending please come along to learn more. My sessions are:

Session ID: 24223

Session Title: The New JSR 107 Caching Standard

Session ID: 24241

Session Title: The Essence of Caching

For the uninitiated JCache is the API being defined in JSR107. It defines a standard Java Caching API for use by developers and a standard SPI (“Service Provider Interface”) for use by implementers.


The stable releases of this software are tagged with version numbers, starting with 0.1. Eventually, when the specification is further along releases will match the specification number.

We expect out first stable release early August 2011.

Snapshot Releases

Snapshot releases of jars for binaries, source and javadoc are available.

Download the cache-api from;quick~javax-cache

or use the following Maven snippet:

    <name>Sonatype Nexus Snapshots</name>



The JavaDoc is available as a jar with the releases. We also have the latest JavaDoc online.


The evolving specification is available online on as a Google Doc.

Reference Implementation

The reference implementation (“RI”) source is available on GitHub.

This implementation is not meant for production use. For that we would refer you to one of the many open source and commercial implementations of JCache.

The RI is there to ensure that the specification and API works.

For example, some things that we leave out:

  • implementation of transactions.
  • eviction does not use an LRU or similar algorithm it just evicts an entry when full.
  • concurrency. The RI is not exhaustively tested for thread safety.
  • tiered storage. A simple on heap store is used.
  • replicated or distributed caching
  • cache sizing. All caches are hard coded to be of size 100 entries.

Why did we do this? Because a much greater engineering effort, which gets put into the open source and commercial caches which implement this API, is required to accomplish these things.

Having said that, the RI is Apache 2 and is a correct implementation of the spec. It can be used to create new cache implementations.

Building From Source

mvn clean install

Mailing list

Please join the mailing list if you’re interested in using or developing the software:


We will be using the #jsr107 channel on Freenode for chat.

We also have set up a commit hook which publishes commits to the channel.

Issue tracker

Please log issues to:


Right now code contribution is limited to the Expert Group, but please feel free to post to the mailing list.


The API is available under the JPA license and may be freely used.

The TCK is available under a restricted TCK license although the tests.

The reference implementation is available under an Apache 2 license.

For details please read the license in each source code file.


This free, open source software was made possible by the JSR107 Expert Group who put many hours of hard work into it.


Creating Terracotta Server Arrays with EC2 CloudFormation for use by Ehcache

This is the first in a series of articles showing how to automate deployment of Ehcache in EC2.

Ehcache is a distributed cache which works with a Terracotta Server Array (“TSA”) which acts as the in-memory store over the network. While Ehcache is simply a jar and is included in your app, provisioning a distributed cache in EC2 requires running up a Terracotta Server Array. Some approaches to this include using Chef, rolling your own AMIs and manual installation.

TSA as a Utility

From the point of view of an application running on EC2. the TSA is a utility. As a utility it would be great if you could provision it much like you do RDS or S3. Now while those are built-in to EC2, CloudFormation templates aim to bring the same ease of provisioning to third party utilities like the TSA.


On 31 May CloudFormation was upgraded with new features: validation for template parameters, resource deletion policies and the ability to block stack creation until your application is ready. Combine that with Ubuntu’s cloud-init feature supported in Amazon Linux AMI and you have a flexible and powerful provisioning infrastructure that you can drive from the AWS Console, command line or SDKs for multiple programming languages. My example uses the Java SDK for CloudFormation.

JUnit Integration Test

This example shows you how to, within a JUnit test, fire up a Terracotta server with CloudFormation and perform an Ehcache integration test. Though relatively simple, it exercises most of the moving parts of CloudFormation.

The example uses standard 32 bit AMIs. It creates a single active Terracotta server, using the open source version.  First it starts an AMI, downloads and installs Terracotta and starts it using the config. We then query the stack to find the EC2 Instance and then use the EC2 API to resolve the public DNS name. Using ehcache.xml’s token replacement feature we then inject the public dns name into the tcconfig and start Ehcache. Ehcache creates a distributed cache across the Internet to the TSA you just created. We then stick something in the cache and read it back out.

You can use this example to set up your own integration testing.

You can check out and run my sample code from GitHub with the following URL: git://

To run the example you need to:

  1. have an AWS account
  2. Edit and add your accessKey and secretKey (available from your account page)
  3. (Optional) Edit and set your keyChainName. It is currently set to gluck. This is an ssh keychain that lets you access the running AMIs.

Though not done in the sample, there are a few other Terracotta deployment options which should be easy with these tools:

  1. Create a tc:config for a striped production cluster
  2. Use a custom terracotta configuration
  3. Place the config on a web server and tart each TC server via a remote URL to the TC:config and the -n switch

In the next article I will show you how to automatically deploy an app using Ehcache to BeanStalk, and how to connect your Ehcache to the TSA created.

JSR107 (Java Caching API) Update – Lots Happening

I have been very busy the last few months getting JSR107 fired up.

Just to remind you JSR 107 is the Java Temporary Caching API. It is designed to be vendor neutral and will allow for easy change over of implementations in much the same way as JPA or JDBC. In this way it will allow the community to choose the best open source or commercial implementation that best meets their business requirements.

Both Terracotta and Oracle have committed resources to getting this done. Right now that is myself and Yannis Cosmadopoulos from Oracle. Things are moving fast so I thought I would give a status update on where we are at.

JSR107 Early Draft Working Specification Available for Viewing

Work has been going steadily on the spec.

We are drafting this spec in the open on Google Docs. While a work in progress, it is now around 40 pages in length.


Please keep checking back as this is changing on a daily basis.

We welcome ideas and feedback. Please join the JSR107 public mailing list to do so.

Summary of Scope

The specification covers the following areas:

Object Cache The API will cache objects. Classes that implement Serializable may be stored outside the JVM and potentially shared among JVMs connected by a network but Serializable will not be required.

Format independence The API will specify keys and values but will not limit their types.

Implementation independence The underlying implementation is hidden from API users. An SPI is used to configure a Cache Provider.

Support for Flexible Implementations Though the specification does not require any implementation and a simple in-process implementation will meet the specification, issues raised by distributed caching and storage in Serialized form outside the heap will be dealt with so that those implementations with those features will work well.

Java SE The specification will work with Java SE.

Java EE The specification will work within Java EE. This specification is targeted at inclusion in Java EE 7.

Generics The specification will make use of generic interfaces.

Annotations The specification will define runtime cache annotations.

Declarative Cache Configuration Specifying the behaviour of the CacheManager or Caches in a non-programmatic way. This may take the form of a minimal lowest common denominator with vendor specific further configuration, or it might take the form of a variety of mechansims to inject vendor configuration.

Transactions Support for transactions, both local and XA will be defined but left as optional for implementers

There are many applied areas of caching. This specification will not deal with them. For example:

• Database Caching. JPA[7] deals with that.

• Servlet Caching

• Caching as a REST service


Active Membership

I am pleased to report that we have a very healthy membership. We reconfirmed the membership, added new members with expertise and also added as observers the leads from JSR342 Java EE7.

The following are active expert group members:

  • Greg Luck, Terracotta and co-spec lead
  • Cameron Purdy, Oracle and co-spec lead
  • Nikita Ivanov, Grid Gain

• Manik Surtani, Red Hat Middleware LLC

• Yannis Cosmadopolous, Oracle and working on the spec for Oracle

• Chris Berry

• Andy Piper (formerly BEA Systems rep)

• Jon Stevens

The following have been voted in they are moving through the JCP process:

• Eric Dalquist

• Ben Cotton, Citigroup

• David Mossakowski, Citigroup

The following are members of JSR342 and are observers of JSR107 (they get the expert group mails):

• Linda Demichiel, Oracle

• Roberto Chinnici, Oracle

GitHub Repositories

Similar to the specification we are also coding up the API in public with repositories on GitHub.




Ehcache via the ehcache-jcache module has provided an implementation of the draft spec to where it got to, for the past 3 years. We have now moved it to GitHub and will develop it along with the spec. If anyone wants to help out please send me your GitHub id.


Public Mailing List

If you want to stay in touch with JSR107, please join our Google Groups public mailing list:

The address is:

We copy most expert group emails to this list.


Comparative Technical Use Cases for Distributed Caches and NoSQL

I have been doing some NoSQL research lately. The first fruit of that work was a guest post on myNoSQL, Ehcache: Distributed Cache or NoSQL Store, which crisply distinguished between a Distributed Cache and NoSQL Stores.

In this article I am going to delve into the suitability of each for various technical use cases. I use the word “technical” because a usual use case is a business use case. Here we are interested in a set of features that allow a certain usage. In a follow up I hope to create a second, more business use case oriented table.

I welcome feedback on this, particularly from those with production experience.

Technical Use Case Distributed Cache NoSQL Key Value NoSQL Columnar NoSQL Graph NoSQL Document
Database Offload Excellent Poor (1) Poor (1) Poor (1) Poor (1)
Database Replacement Poor (2) Poor (3) Poor (3) Poor (3) Poor (3)
Weak Consistency Caching Excellent Average (2) Average Poor Poor
Eventual Consistency Caching Excellent (4) Average (5) Average (5) Average (5) Average (5)
Strongly Consistent Caching Excellent Poor Poor Poor Poor
ACID Transactional Caching Excellent Poor Poor Poor Poor
Low Latency Data Access Excellent Average (5) Average (5) Average (5) Average (5)
Big Data (6) Poor Excellent Excellent Excellent Excellent
Big Memory (7) Excellent (8) Poor Poor Poor Poor


  1. To offload the database you need to work in places and ways in which the database works. So for example you need to support transactions if they are being used and you need a place to plug in to avoid a ton of work like Hibernate or OpenJPA. NoSQL stores don’t do that.
  2. Distributed caches may not provide long term persistence and management of data. They are also often limited in size so may not be able to store all of the data.
  3. It is not clear that NoSQL is a full database replacement. The “Not Just SQL” as an alternative expansion of the acronym, something widely accepted by the NoSQL community, acknowledges this. The lack of SQL, the lack of ACID, sophisticated operations tools and so on, mean that NoSQL itself is not great at being a replacement. Rather, if you can rethink your need for a database to needing persistence, and you can change your application code, then it comes into play.
  4. In a node to the elegant CAP trade off allowed by eventual consistency, Ehcache 2.4.1, due out the end of March adds this consistency mode.
  5. Distributed Caches store hot data in process. You might think of memcache as a distributed cache, which it claims to be but it does not store data in -process – it is always over the network. And NoSQL is always over the network. In most R + W > N strategies, R is greater than one, so that multiple network reads are required and the caller must wait for R reads where each read is to a different server which will have a varying response. Distributed Ehcache has latencies of < 1 ms whereas the average for NoSQL is 5-10ms. This is also why NoSQL gets an average for Weak Consistency Caching. A cache should be fast.
  6. “Big Data” is a moving target that is today generally understood to start at a few dozen terabytes and go up into petabytes. The current implementation of Ehcache has been used to manage datasets up to 2 TB which is just at the starting point of Big Data. The whole point of NoSQL is Big Data, so they get full marks in this area.
  7. “Big Memory” is also a moving target and is early on it’s use as a term. We define it to mean using the physical limits of the hardware. For many architectures this has not been possible. With Java the issue was first 32 bits and then now the limitation is garbage collection. We overcame that issue with our BigMemory architecture, using storage in off-heap byte buffers in September 2010.
  8. Caches tends to be memory-resident. BigMemory allows in-memory densities per physical server up to their limits, which is 2TB for the current generation of commodity hardware from Dell, HP and Oracle but much lower due to their architectures which require full CPU population to achieve maximum memory. Although not all vendors are similarly constrained: Cisco UCS boxes allow more memory per CPU, so that for example they can do 384GB with 2 CPUs. NoSQL stores focus on persistency and have small in-memory server side caches. They focus on speeding up disk reads and writes by for example doing append only.