BT

Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ

Topics

Choose your language

InfoQ Homepage News JCACHE Specification Finalized

JCACHE Specification Finalized

Leia em Português

This item in japanese

Lire ce contenu en français

Bookmarks

Oracle announced this month that the JCACHE specification is now final. JSR-107 was the oldest living JSR on the books, and was initiated on March 6, 2001. After thirteen years of evolution and development, the "Java Temporary Caching API" will bring Java a common interface for interacting with caching systems.

Oracle had received high levels of interest for JCACHE to be included in last year's Java EE 7 release, but after missing "a few critical deadlines", the JSR was dropped from the candidate list. Following Oracle's recent Java EE 8 survey, nearly two-thirds of all respondents expressed an interest in having JCACHE included as part of the language's next Enterprise Edition. With the announcement of the specification's finalization, Oracle made note that the project's reference implementation can be used as a drop-in to a Java EE 6 or Java EE 7 application, without having to wait for Java EE 8.

In itself, JCACHE provides a Map-like API for accessing caches, SPIs for spooling caches to persistent disk, an API for retrieving a named cache, and an API for registering event listeners. It does not, however, specify strategies for eviction, replication, or transactions. The work for defining those characteristics of caching is being done as part of JSR-347 - JGRID, to which JCACHE is a preceding and foundational component.

InfoQ caught up with Ben Cotton, who is a member of both the JSR-107 and JSR-347 expert groups, to ask some questions about JCACHE and the future of caching on the JVM:

InfoQ: Why JCACHE?

JCACHE will do for the Java Caching community exactly what JDBC did for the Java RDBMS community.

It promises to give Java a standard API with which JCACHE programmers can transparently operate on their data operands, independent of their data locality. With explicit join points to Hibernate and JPA L2 views, It won't matter if the data operand is a column in a data base, or a Map.Entry

InfoQ: What do you have planned for the future?

Transactional support has been high in demand, so we are working on that. Additonally, we are building in support for JGRID interaction. Also, we are opening up transparent API hooks to ultra-premium Java locality libraries' data operands (ie. Peter Lawrey's OpenHFT SharedHashMap)

In addition to the open source reference implementation, the JSR-107 specification is freely available on the project's GitHub page, including issue and commit history.

Rate this Article

Adoption
Style

BT