This package contains the API for JCache. JCache describes the technique whereby Java developers use a javax.cache.spi.CachingProvider to temporarily cache Java objects. It provides a common way for Java programs to create, access, update and remove entries from caches.

Core Concepts

The Java Caching API defines five core interfaces: javax.cache.spi.CachingProvider, javax.cache.CacheManager, javax.cache.Cache, javax.cache.Cache.Entry and javax.cache.expiry.ExpiryPolicy.

A javax.cache.spi.CachingProvider defines the mechanism to establish, configure, acquire, manage and control zero or more javax.cache.CacheManagers. An application may access and use zero or more javax.cache.spi.CachingProviders at runtime.

A javax.cache.CacheManager defines the mechanism to establish, configure, acquire, manage and control zero or more uniquely named javax.cache.Caches all within the context of the javax.cache.CacheManager. A javax.cache.CacheManager is owned by a single javax.cache.spi.CachingProvider.

A javax.cache.Cache is a Map-like data-structure that permits the temporary storage of Key-based Values, some what like java.util.Map data-structure. A javax.cache.Cache is owned by a single javax.cache.CacheManager.

An javax.cache.Cache.Entry is a single key-value pair stored by a javax.cache.Cache.

Each entry stored by a javax.cache.Cache has a defined duration, called the Expiry Duration, during which they may be accessed, updated and removed. Once this duration has passed, the entry is said to be expired. Once expired, entries are no longer available to be accessed, updated or removed, just as if they never existed in a javax.cache.Cache. Expiry is set using an javax.cache.expiry.ExpiryPolicy.

Store-By-Value and Store-By-Reference

Entries are stored by individual javax.cache.Caches using one of two mechanisms: store-by-value and store-by-reference.

Store-By-Value

The default mechanism, called store-by-value, instructs an implementation to make a copy of application provided keys and values prior to storing them in a javax.cache.Cache and later to return a new copy of the entries when accessed from a javax.cache.Cache.

The purpose of copying entries as they are stored in a javax.cache.Cache and again when they are returned from a javax.cache.Cache is to allow applications to continue mutating the state of the keys and values without causing side-effects to entries held by a javax.cache.Cache.

Store-By-Reference

The alternative and optional mechanism, called store-by-reference, instructs a javax.cache.Cache implementation to simply store and return references to the application provided keys and values, instead of making a copies as required by the store-by-value approach. Should an application later mutate the keys or values provided to a javax.cache.Cache using store-by-reference semantics, the side-effects of the mutations will be visible to those accessing the entries from the javax.cache.Cache, without an application having to update the javax.cache.Cache.

javax.cache.Caches and java.util.Maps

While javax.cache.Caches and java.util.Maps share somewhat similar APIs, javax.cache.Caches are not Maps and java.util.Maps are not javax.cache.Caches. The following section outlines the main similarities and differences.

Like java.util.Map-based data-structures:

• javax.cache.Cache values are stored and accessed through an associated key.
• Each key may only be associated with a single value in a javax.cache.Cache.
• Great care must be exercised if mutable objects are used as keys. The behavior of a javax.cache.Cache is undefined if a key is mutated in a manner that affects equals comparisons when a key is used with a javax.cache.Cache.
• javax.cache.Caches depend on the concept of equality to determine when keys and values are the same. Consequently custom key and value classes should define a suitable implementation of the java.lang.Object#equals method.
• Custom key classes should additionally provide a suitable implementation of the java.lang.Object#hashCode() method.

  Although recommended, implementations are not required to call either the Object.hashCode or Object.equals methods defined by custom key classes. Implementations are free to use optimizations whereby the invocation of these methods is avoided.

  As this specification does not define the concept of object equivalence it should be noted applications that make use of custom key classes and rely on implementation specific optimizations to determine equivalence may not be portable.

Unlike java.util.Map-based data-structures:

• javax.cache.Cache keys and values must not be null.
• Any attempt to use null for keys or values will result in a java.lang.NullPointerException being thrown, regardless of the use.
• Entries may expire.
• Entries may be evicted.
• To support the compare-and-swap (CAS) operations, those that atomically compare and exchange values, custom value classes should provide a suitable implementation of java.lang.Object#equals.

  Although recommended, implementations are not required to call the java.lang.Object#equals method defined by custom value classes. Implementations are free to implement optimizations whereby the invocation of this method is avoided.

• Implementations may require Keys and Values to be serializable in some manner.
• javax.cache.Caches may be configured to control how entries are stored, either using store-by-value or optionally using store-by-reference semantics.
• Implementations may optionally enforce security restrictions. In case of a violation, a java.lang.SecurityException must be thrown.

Consistency

Consistency refers to the behavior of caches and the guarantees that exist when concurrent cache mutation occur together with the visibility of the mutations when multiple threads are accessing a cache.

All implementations must support the Default Consistency model as outlined below.

Default Consistency

When using the default consistency mode, most javax.cache.Cache operations are performed as if a locking mechanism exists for each key in a javax.cache.Cache. When a cache operation acquires an exclusive read and write lock on a key all subsequent operations on that key will block until that lock is released. The consequences are that operations performed by a thread happen-before read or mutation operations performed by another thread, including threads in different Java Virtual Machines.

For some javax.cache.Cache operations the value returned by a javax.cache.Cache is considered the last value. The last value might be an old value or a new value, especially in the case where an entry is concurrently being updated. It is implementation dependent which is returned.

Other operations follow a different convention in that mutations may only occur when the current state of an entry matches a desired state. In such operations multiple threads are free to compete to apply these changes i.e. as if they share a lock.

As these methods must interact with other javax.cache.Cache operations acting as if they had an exclusive lock, the CAS methods cannot write new values without acting as if they also had an exclusive lock.

See the JCache Specification for further details.

Further Consistency Models

An implementation may provide support for different consistency models in addition to the required Default Consistency mode

A Simple Example

This simple example creates a default javax.cache.CacheManager, configures a javax.cache.Cache on it called “simpleCache” with a key type of String and a value type of Integer and an expiry of one hour and then performs a some cache operations.

//resolve a cache manager
CachingProvider cachingProvider = Caching.getCachingProvider();
CacheManager cacheManager = cachingProvider.getCacheManager();

//configure the cache
MutableConfiguration<String, Integer> config =
   new MutableConfiguration<>()
   .setTypes(String.class, Integer.class)
   .setExpiryPolicyFactory(AccessedExpiryPolicy.factoryOf(ONE_HOUR))
   .setStatisticsEnabled(true);

//create the cache
Cache<String, Integer> cache = cacheManager.createCache("simpleCache", config);

//cache operations
String key = "key";
Integer value1 = 1;
cache.put("key", value1);
Integer value2 = cache.get(key);
cache.remove(key);