Q&A with JCache Spec Lead Greg Luck

The JCP Expert Group in charge of JSR 107, the specification for the Java Temporary Caching API, better known as JCache, recently submitted the maintenance review for JCache 1.1.1. This is just an errata release and not particularly newsworthy, but it marks something of a milestone for the longest running spec request in the history of Java. And it seemed like a good time to talk with its co-author.

Greg Luck is the CTO of Hazelcast and co-spec lead on JSR 107 with Oracle software architect Brian Oliver, who works on the Coherence team. Hazelcast develops, distributes and supports a leading open source in-memory data grid (IMDG), also called Hazelcast. Oracle was the original submitter of the JCache spec, and Luck is the creator of Ehcache, a well-known version of that spec.

How did you become involved with this JSR?
I was doing some work for a big online share-trading company at the time, and they wanted me to create a JCache adapter for Ehcache. I tried to do it, but the spec wasn't complete, so, I told them that, and they said, well, can't you do some work on the spec? And that's how I got roped into it, though I didn't really have time to work on it until I was at Terracotta.

When you started working on caching technologies back in the day, it had sort of bad reputation, didn't it?
At the time, people felt, in the Java community, very, very strongly, that caching was a dirty trick, that if you were to do that, there was something wrong with your architecture. It was the very strong prevailing view. One of the reasons engineers felt that way is that caching is very seldom black and white. It's probabilistic in nature, a bit like AI techniques using statistics.

But it's a completely different era now. People came to realize that anything done at Web scale must be done with caching. Every single cloud provider now has, as a standard component, a caching service along with the different implementations they provide. It's now well understood that caching has a purpose.

Do I have it right that JSR 107 was the longest-running spec request?
It was, but I think it was worth the wait. It's now considered one of the most -- if not the most -- successful stand-alone specs, ever.

How do you measure that success?
In terms of the number of implementations. There are 13 now, and we recently saw IBM implement JCache for its eXtreme Scale API. It really has been enormously successful. The spec has been implemented now by so many people that it's a standard that can just be used and leveraged in all these different products.

One of those implementations -- Blazing Cache -- was created by the travel Web site Trivago. These guys actually created a cache for their own purposes for that huge site.

At Hazelcast we actually have some of our biggest customers using us for our JCache. I get in trouble if I say who these companies are.... In fact, our biggest production cluster in the world, which is an online store that services billions of people, uses us for our JCache.

At this point there is only one significant implementation in the caching world that has not adopted it: Pivotal's Gemfire, and its open source variant, Apache Geode. I don't entirely understand why. The guys tend to be Spring-centric, and Spring itself has got good support for JCache. I guess you could say that JCache is ubiquitous with one exception.

What's going on with this release?
It's a self-serving comment, but I have to say that 1.0 was pretty well done. There were a few things found in 1.1. And now 1.1.1 is really just an errata release. This thing is pretty mature and stable, and I think it's enormously important to the Java community. It's been out there now for four years, it can be used as a foundation.

I understand that you'd like to see JCache implemented in Jakarta and MicroProfile, both of which are now at the Eclipse Foundation.
If you look at the surveys, JCache is the number one thing people are asking to be included in the Jakarta spec. And I've been personally lobbying the MicroProfile people to add caching, because it's incredibly important. We [Hazelcast] joined MicroProfile, and I wrote a specification to include JCache in MicroProfile. Tons and tons of Hazelcast gets used with microservices, so it's clear to me that having the framework directly support it would be great. But the MicroProfile guys don't currently see caching as a priority, so nothing has happened yet. Jakarta has become energized under the stewardship of Eclipse, so we'll see what happens there.

What's your pitch to the MicroProfile folks?
With microservices, you take a monolithic application and you break it into pieces. You essentially have a container that you started from Java, and it's probably running in Docker. If it's a busy microservice, you'll want to scale it. With microservices, you can easily scale just the bit you want. Let's say you started with three and you want to scale it up ten or fifteen. If you pop an in-memory data grid (IMDG) in there, it can run in process, so it's in each of the nodes. And then, as you scale the thing, the IMDG scales along with it, literally.

So, IMDGs, through their embeddable nature in Java, are the perfect fit for microservices. If someone wants to build a microservice, if they use JCache, they can use their IMDG and they can use a first-class annotations library that's in JCache, and they can swap the IMDG at a very low cost.

The MicroProfile people are just leaving this as something the implementor has to deal with. But having caching as a first-class citizen inside the MicroProfle framework would be very useful for a lot of people.

And yet, one of the relatively unique qualities of JCache is that it's a stand-alone spec.
That is true. Because it's one of the few stand-alone specs, people can very easily just plug it in and use it. If you use a caching API in your code, if you use JCache, you can swap out implementations at no cost, which is always the promise of these things.

Posted by John K. Waters on February 13, 2019