JAXenter: Congratulations on joining the Eclipse Foundation
. Why did Hazelcast decide to join the Eclipse Foundation? What was the motivation behind the move?
Greg Luck:For some time we have been successively working with the Eclipse Foundation on a number of open source projects. Given our work on Eclipse MicroProfile and the fact that Oracle has moved stewardship of Java EE technologies to the Foundation, we felt it was the right time to become even more involved.
JAXenter: What will Hazelcast focus on in this new arrangement?
Greg Luck: Our primary focus will be on JCache, the Eclipse MicroProfile, and EE4J. In particular, we will be collaborating with members to popularize JCache, a Java Specification Request (JSR-107) which specifies API and semantics for temporary, in-memory caching of Java objects, including object creation, shared access, spooling, invalidation, and consistency across JVM’s. These operations help scale out applications and manage their high-speed access to frequently used data. In the Java Community Process (JCP), I have been the co-spec lead and then maintenance lead on “JCache – Java Temporary Caching API” since 2007.
JAXenter: Why is it important to popularize JCache? What’s in it for Hazelcast?
In a community vote on Java EE features in 2016, JCache support was the most requested feature.
Greg Luck: JCache standardizes caching for the Java platform: it is a common mechanism to create, access, update, and remove information from caches. It will accelerate mainstream adoption of in-memory computing by giving all Java developers an easy-to-use and standard way to access memory from within Java. Enterprises will greatly benefit from the increased speed and scalability of applications written to take advantage of JCache and will be able to change providers without having to rewrite their applications or maintain a proprietary bespoke cache abstraction layer.
There are now 14 implementations of JCache. There is one for almost all In-Memory Data Grid and every Distributed Java Cache and every in-process Java Cache. As a result, there is high use. Spring has for many years supported JCache. Getting it out to the non-Spring enterprise frameworks remains a work in progress.
In a community vote on Java EE features in 2016, JCache support was the most requested feature. There is also interest in adding it to MicroProfile. We remain a member of the JCP Executive Committee and we have now joined the Eclipse Foundation to be in a position to promote JCache.
Hazelcast IMDG enables organizations to seamlessly integrate with JCache. The JCache caching layer API provides a standard set of operations specialized for caching use cases. These operations can help to scale out applications and manage their high-speed access to their frequently used data. Hazelcast smoothly achieves its caching potential with a 100 percent compliant implementation that transparently registers with the JCache subsystem. Popularization of the JCache standard makes it easier for companies to use Hazelcast IMDG as their primary cache provider.
JAXenter: After Oracle decided to move Java EE technologies to the Eclipse Foundation, discussions about merging EE4J and Eclipse MicroProfile started to appear. Do you think these two projects should be merged?
I am not sure they need to be merged. Given that EE is actually a collection of other JSR standards, these can be imported as they make sense into MicroProfile.
Greg Luck: I have been on the mailing list, have had some conversations and know the people involved. I would say that this is an evolving situation with good will on both sides. MicroProfile emerged partly due to the faltering commitment of Oracle to Java EE. On Oracle’s side, I think they have spent a lot of money and effort on EE and it was becoming uneconomic for them. Java itself goes from strength to strength but there has been a decisive move away from the large many applications deployed to one app server model that we used to have.
Hazelcast, being embeddable, is uniquely suited to Microservices. Our Microservices whitepaper has been about the most popular thing on our website since we released it last year. So we wanted to do more with it and thus our support for MicroProfile.
I am not sure they need to be merged. Given that EE is actually a collection of other JSR standards, these can be imported as they make sense into MicroProfile. Version 1.2 of MicroProfile now includes Health Check 1.0, Metrics 1.0, Fault Tolerance 1.0, JWT Propagation 1.0, updated Config 1.1 in addition to CDI 1.2, JSON-P 1.0 and JAX-RS 2.0 so it has imported some from EE.
JAXenter: Hazelcast has demonstrated time and time again that they are committed to open source. How do you plan to continue this commitment as a member of the Eclipse Foundation? Are there any specific plans?
Greg Luck: You’re right, as a company we are fully committed to driving adoption of open standards, along with ensuring Java remains the premier enterprise software platform. Hazelcast was the first open source in-memory data grid, introduced in 2008 under an Apache 2 license.
We continue to be adopted by open source projects and those wishing to build their products with open source stacks. I think this is because we’re trusted and continue to heavily invest in improving Hazelcast. Besides participating in MicroProfile and EE4J projects, Hazelcast has no other specific plans.
JAXenter: The migration from Java EE to EE4J is well on track with the announcement of nine new project proposals
for EE4J. We have Eclipse Grizzly, Mojarra, Tyrus, Jersey and more — Are you involved in any of these projects?
Greg Luck: We are not directly involved in any of these. We solve one part of the puzzle, stay focused on that, and try to do it very well.
JAXenter: How would you characterize the future of the open source Enterprise Java? What should we expect in 2018 and beyond?
Greg Luck: Spring continues to go from strength to strength. So I would expect more of that. The non-Spring world, which has been languishing, now has new energy and a lodestone in the Eclipse Foundation. I expect good things, and we will help as appropriate.