After 13 years, JCache specification is finally complete

How can people learn about using JCache?We’ve created a website called JCache.org. Back in the day, Sun had a page where you could see a couple implementations of specifications. This is like that. We’ll be adding more implementations as they are released.

The other thing with JCache, because it’s new and the vendors have just implemented this literally weeks ago, a lot of people don’t know about it. It’ll be a big thing after JavaOne. This is a topic where the interest level will slowly rise as more vendors implement. It’s probably the most interesting thing going into Java EE 8.

Inside the Java world, implementations are available, but do you expect non-Java-specific data stores to implement it as well?We definitely kept this in mind when we did the specification. I can see Memcached or a NoSQL implementing the main classes, like cache manager and cache entry, so you can do the basic operations across a wide range of implementations. If you want TCK compliance, then you have to go with a Java-based in-memory data grid to get full compliance. All those have proprietary APIs, and the whole point of JCache is that you can swap it out with no code change.

What have you been working on at Hazelcast?We’ve been doing a big investment this year to raise the quality to enterprise grade. For version 3.3, the focus has been stability and quality. We’ve been rewriting the documentation as well. The plan is to come out with zero open bugs.

The next place we’re going to is high-density cache. As a rule of thumb, an untuned JVM will produce a 1-second-per-GB pause [for garbage collection]. A 100GB heap might pause for 100 seconds, and bad things happen when it does. This is meant that Java itself as a language is not really that suitable for doing maximum allowed pause limits for in-memory computing.

The Java Non-blocking I/O stuff that was put in five or six years ago puts data in these direct byte buffers outside the Java heap area so you don’t get these pauses.

What we’re doing in Hazelcast is what we call high density. Our approach, rather than going off heap, is to create large byte arrays on heap. We can get hundreds of gigabytes in the JVM without going off heap. We have an on-heap slab allocator. We want to combine this with JCache, which is simple to use and widely distributed but also [supported] in lots of other things. We want to make it work great, and also make it high density so you can have terabyte-size caches.