Enterprise Java

Java Temporary Caching API – Test-driving the Early Draft Review RI

It was known as ‘ The Neverending Story‘. The JSR kicked of 11 and a half year ago and passed the JSR Review Ballot on 06 Mar, 2001. If you ever wondered what it takes to get a fancy low JSR number in the hundreds: That is the secret. Unlike in the German fantasy novel by Michael Ende this was not about people’s lack of imagination but about resources, political discussions and finally about licensing. But let’s forget about the past and move to what is there since yesterday. Note that this material was uploaded to the JCP in February but was delayed while the legal complications of having two companies as shared spec leads got sorted out. That is done and will not be an issue going forward in the process.

What is it all about?

Caching is known for dramatically speeding up applications. Those typically use temporary data which is expensive to create but has a long lifetime during which it can be re-used. This specification standardizes 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.

It is designed to work with both Java SE and Java EE. For the later it still is not ensured, that it will be included in upcoming EE 7 release but the EG is working hard on it and needs your feedback.

How do I get my hands on it?

That is easy. All the needed artifacts are in maven central already. Let’s build a very simple sample for you to get you started. Fire up NetBeans and create a new Maven Java Application. Name it whatever you like (e.g. cachingdemo, open the pom.xml and add the following two dependencies to it:



And if you are there, change the junit version to 4.8.2.

Refactor the AppTest to utilize the new junit:

package net.eisele.samples.cachingdemo;

import org.junit.Test;

 * Simple Cache Test
public class AppTest {

    public void testApp() {

All set. To make this simple, I’m going to add some caching features in the test-case.

The Basic Concepts

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. Like a map, data is stored as values by key. You can put values, get values and remove values. But it does not have high network cost map-like methods such as keySet() and values(). And generally it prefers 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).

 // Name for the cache
        String cacheName = 'myfearsCache';
        // Create a cache using a CacheBuilder
        Cache<Integer, String> cache = Caching.getCacheManager().<Integer, String>createCacheBuilder(cacheName).build();
        // define a value
        String value1 = 'Markus';
        // define a key
        Integer key = 1;
        //put to the cache
        cache.put(key, value1);
        // get from the cache
        String value2 = cache.get(key);
        //compare values
        assertEquals(value1, value2);
// remove from the cache
        // ceck if removed

Things to come
This basically is all that is possible at the moment. Going down the road with subsequent releases you should be able to:

– Integrate with Spring and CDI via @Annotations
– Use CacheEventListener
– Work with Transactions

The EG is actively searching for feedback on the available stuff. So, if you can get your hands on it, give it a try and let the EG know what you think!

Links and Reading

JCP page:
JSR 107: JCACHE – Java Temporary Caching API

Group Mailing List

Log issues in the Issue Tracker

A very simple demo

ehcache-jcache – an implementation of the 0.5 specification

Reference: Java Temporary Caching API – Test-driving the Early Draft Review RI from our JCG partner Markus Eisele at the Enterprise Software Development with Java blog.

Markus Eisele

Markus is a Developer Advocate at Red Hat and focuses on JBoss Middleware. He is working with Java EE servers from different vendors since more than 14 years and talks about his favorite topics around Java EE on conferences all over the world. He has been a principle consultant and worked with different customers on all kinds of Java EE related applications and solutions. Beside that he has always been a prolific blogger, writer and tech editor for different Java EE related books. He is an active member of the German DOAG e.V. and it's representative on the iJUG e.V. As a Java Champion and former ACE Director he is well known in the community. Follow him on Twitter @myfear.
Notify of

This site uses Akismet to reduce spam. Learn how your comment data is processed.

1 Comment
Newest Most Voted
Inline Feedbacks
View all comments
Tim Boeckstaens
11 years ago

I have to say I haven’t yet looked at the spec yet. Will there be support for the time an object will be kept inside the cache or a maximum size of the cache?

Back to top button