The open-source, in-memory compute provider Hazelcast announced the release of Hazelcast 3.3.1, implementing JCache (JSR 107, the Java Temporary Caching API), during JavaOne 2014 last week. This release is the first Hazelcast release to implement JCache, bringing the number of JCache-compatible GA products to three (joining Coherence and Ehcache). InfoQ spoke to Greg Luck, CEO of Hazelcast (formerly CTO) and Miko Matsumura (CMO, Hazelcast) during JavaOne.

InfoQ: Describe Hazelcast's year?

Luck: We've raised $11M in venture capital, we've released 3.3, which represents a whole new level of quality in the product. We've created a simulator called Stabilizer to performance test scenarios and configurations for Hazelcast. We do 2-day runs on clusters of various sizes, for environments such as EC2 and Google App engine. For selected customers we will even replicate their clusters to try to reproduce any issues they're having.

Luck: On Monday 29th September we released 3.3.1 with our JCache implementation. We are the only implementation built from the ground up to be compliant with JSR 107 (JCache). We were the third to get our implementation out, but we're the only one that's not a wrapper over an existing API. So that took a little longer than I'd have liked, but technically I'm really happy.

InfoQ: Can you speak to your competition with Coherence, and explain how your open-source strategy plays into this?

Luck: As we get larger we need to be of the same quality as Coherence, but we are definitely an open-source product. We released Stabilizer as open-source (https://github.com/hazelcast/hazelcast-stabilizer). The same is true of the TCK (Testing Compatibility Kit) - I just added a paragraph to our wiki showing how to validate against the JSR 107 TCK - so anyone can verify that we're a compatible implementation.



InfoQ: Why did you join Hazelcast?

Luck: I've been doing in-memory computing for a decade now, starting with Ehcache. I did it in the best possible way - by serving my own need. The most extreme thing you can do in that space is in-memory data grid. I like continuing the story up from Ehcache and Terracotta. I felt confident about the demand for in-memory data grids and that it's not a space that's done yet. We have a strong incumbent and I feel there's room for a strong open-source competitor. I didn't anticipate becoming CEO (Luck joined as CTO in Jan 2014), but whatever it takes. I am a very technical CEO.



InfoQ: What are your future plans? Can you discuss the evolution of this space and Hazelcast's niche within it?

Luck: One new thing is in-memory compute as a separate category (as reported by Gartner and Forrester). This was started by SAP's Hana. On the other hand, analysts have halved the size of the NoSQL market, to $3.7bn, while in-memory is growing.

Luck: So, is Hazelcast a NoSQL? Some people do think of us as one - for example, there was a Rebel Labs survey recently that had Hazelcast ranked as the #4 Primary NoSQL technology after MongoDB, Cassandra and Redis. For myself, I look at what our customers are using us for, and I think of how to perfect our in-memory grid.



InfoQ: What about JSR 107 (JCache)?

Luck: I see JSR 107 as enabling what I call "Hi-Density Caching (HDC)". This involves a JCache API, with a number of different possible stores. Obviously, this includes an off heap store, but there's also an on-heap slab allocator, which can handle up to 200Gb. That 200 GB is represented as 10 byte arrays of 20Gb each. We force an initial GC (via System.gc()) to pin the arrays to the tenured generation, and then they don't move again. We want to release a first version of this technology by end of 2014.

Luck: JSR 107 makes multiple techniques available to our customers, including the traditional off-heap approach. It provides a standard way to think about managing data and datasets, and in a way JSR 107 is the easiest "NoSQL" interface to use. One key use case for HDC is large-scale ecommerce and web sessions.

Luck: At the next tier up, we see a concept we call "Operational Store". This sits over JCache, HDC and persistence components, and is for cases where the in-memory store is not optional, and persistence only records transactions that have already completed. Big features here include restartablity of services.

Matsumura: There's a huge market for us just in that core space. Obvious customers include financial services, telco, ecommerce, logistics and ticketing. Of course, it's open-source, and represents a huge democratization of advanced tech by leveraging what's been done with JCache.

Luck: It will definitely evolve, because trying to standardize in-memory is tricky. What aspects would you standardize? After all, where's the standard for map-reduce? To me, in-memory would be a collection of JSRs, the first of which is JCache. There might be a case to do a JCache v2 with transactional support. We do also really need a web sessions standard.

Matsumura: I thought the web sessions "standard" was called "Tomcat".

InfoQ: Which JSRs do you see as being strategic? What do you think of the proposals for EE 8?

Luck: For EE 8, JCache is at top of my list, obviously. The servlet and new HTTP/2 ideas sound good, also CDI 2.0. Turning it round, I'd be unhappy if JPA were try to standardize NoSQL. One thing we definitely don't need is more unused standards. Standards have to be used. To use JCache as an example, the standard came out in March and we already have 3 implementations. In fact, it's almost 4, as I hear the Infinispan team are nearly there on passing the TCK as well.

InfoQ: What prompted Hazelcast to run for the JCP Executive Committee (EC)?

Luck: I was on the EC as Software AG's rep (this was a ratified seat, nominated by Oracle). I thought I was a sensible contributor to the JCP and I've used a lot of JSRs, but I'm not a "shiny new toy" kind of guy. I jumped on Jersey early, but I'm not often an early adopter. Whilst on the EC, I voted no on some things, but things which should be voted No to, because they weren't right for standardization.