Infinispan, Red Hat's distributed, in-memory, key-value store, recently announced a release that supports the JCache caching API for Java applications (JSR 107). InfoQ talked to one of the principal engineers from the Infinispan project, Galder Zamarreño, about this important milestone.
InfoQ: Infinispan 7.0.2 was released just before the holidays, and includes JCache (JSR-107) support. That standard took quite some time to be produced - can you explain your involvement in the process and the benefit you see in supporting it?
Galder Zamarreño: I started getting involved with JSR-107 when I took over an Infinispan prototype implementation of JSR-107 version 0.5 that my colleague Vladimir Blagojevic started. From that moment on I started to provide feedback regularly.
Infinispan started to provide pre-release versions early on because we believed it was key to the adoption of Infinispan. Before JSR-107, each caching implementer had their own set of definitions and terms, which could cause confusion amongst users. With a defined set of terms and API, it’s easier to engage with the community and get our functionality more easily understood.
InfoQ: There are now 4 certified commercial implementations of JCache, and caching is a diverse and highly competitive market of increasing value. What benefits do you see standardisation bringing to the end-user of caching technologies?
Zamarreño: As well as providing a set of defined terms and functionality, standardisation provides a great opportunity for the end-user to easily compare how the different caching technologies behave in terms of performance, memory consumption...etc., depending on their caching use case. When we first started Infinispan we built a tool called Radargun for benchmarking different caching frameworks, and we have to develop multiple plugins for each caching provider that we wanted to test. With JCache this becomes much simpler since there’s a common API now.
InfoQ: What differentiates Infinispan, and what makes your customers choose you over, say Coherence or Hazelcast?
Zamarreño: Our customers see Infinispan as the leading open-source alternative to Coherence. They use Infinispan broadly in 3 use cases: as a distributed side cache with a database, as the primary high-performance store for unstructured data and as an in-memory compute grid. Through our open-source product Red Hat JBoss Data Grid, we support an enterprise version of Infinispan which is very economical compared to Coherence and uncompromising in performance and scalability.
We also test and certify integrations of Red Hat JBoss Data Grid with our other middleware products such as Red Hat JBoss Enterprise Application Platform, Red Hat JBoss, JBoss Fuse, and Red Hat JBoss Data Virtualization. Our customers find it attractive to get end-to-end support for a well-integrated, open-source middleware stack from a single company with strong enterprise credentials.
InfoQ: Which other JSRs do you see as being strategic for Infinispan & what do you think of the proposals for EE 8?
Zamarreño: Infinispan has been powering caching within Red Hat JBoss Enterprise Application Platform, which currently implements EE 7 since the project was founded. As the next Red Hat JBoss Enterprise Application Platform versions adopt EE 8, we’ll be working with other EE 8 technologies, such as JPA and EJB, to make sure that they make the most of the standard Java Caching API. Hence EE 8 is very important for both Infinispan and our JCache implementation.
InfoQ: What are your future plans - both long term and in terms of roadmap for 2015?
Zamarreño: For 2015 we’re going to work a lot on Infinispan’s ergonomics to provide auto-tuning, improve memory efficiency, simplify configuration and revamp monitoring and management. We will also continue to bring our Server offering in line with Core in terms of functional parity. Finally, we’ll be integrating closely with the Hadoop ecosystem.
InfoQ: Do you have any other comments about your recent release or the caching market in general?
Zamarreño: I’m very keen on functional programming and the arrival of Java 8 will be a game changer for all existing APIs, in particular caching APIs. In essence a lot of the existing caching APIs, included the ones in JCache, are based around executing a function against a key or a set of keys. Hence I think caching APIs are open to a lot of simplification using functional APIs.
However a deterrent for these kind of APIs might be the lack of serialization in lambda expressions in Java. Other JVM languages such as Scala allow for lambda functions and closures to be distributed, but they have a lot of caveats due to the possibility for these expressions to reference non serializable objects. Scala’s Spores functionality (http://docs.scala-lang.org/
sips/pending/spores.html) is designed to address this and provide a safer way to distributed lambdas and closures. I’d love to see something similar in the Java space.
Galder Zamarreño is a core R&D engineer at JBoss, a division of Red Hat. He is one of the founding engineers of Infinispan. His Java caching experience is extensive, which includes creating the Infinispan-based Hibernate Second Level Cache which works both in local and distributed environments and is the default implementation used in JBoss Application Server 7 and Wildfly. The love for distributed systems and open source software comes from his days at ESIDE faculty at University of Deusto (Bilbao, Spain) where he studied for a Master's degree in Computer Science.
