By introducing a Java specification for its own Infinispan data grid technology, open-source software provider Red Hat has generated a lively debate within the ranks of the JCP (Java Community Process) over the best way to add distributed caching to enterprise Java.
If implemented in the next version of JEE (Java Enterprise Edition), Red Hat’s specification could reduce the need for separate Java distributed caches, such as Oracle’s Coherence, VMware’s GemStone or Terracotta’s open-source Ehcache, argued Craig Muzilla, vice president and general manager of Red Hat’s middleware business.
“What we’re proposing here is similar [to those products], but it will be a standard, and integrated with Java EE,” he said.
But while many in the Java enterprise community agree that a distributed in-memory cache is needed, not everyone thinks that Red Hat’s approach is the best solution.
“While trying to appear beneficial to the community, Red Hat is actually pulling a very self-beneficial move–get their product out in front of the community,” said Amit Pandey, CEO of Terracotta. “They are trying to pull a fast one.”
On Thursday, Red Hat submitted to the JCP (Java Community Process) an as-of-yet-unnumbered JSR (Java Specification Request) that describes the data cache, in hopes the body will include the technology in Java Enterprise Edition 7, due next year.
The work is based off of the company’s still-experimental open-source Infinispan data grid distributed cache software.
Like other distributed data caches, Infinispan solves the problem of “input/output bottlenecks going to and from the database,” Muzilla explained. With Infinispan, “you can load up the entire database in memory, and relate to that data through an object-relational format. The application does not need to continually go back to the database.”
The need for such caches has been growing, especially in the burgeoning field of cloud computing, Muzilla explained. And the enterprise Java community has indicated as much.
“We have been using cache for a decade in all the layers of our architecture. We know how to make caches, so why not specify them[?]” Antonio Goncalves, a developer who is part of the JCP’s Java EE 6 expert group, wrote in a much-discussed online “wish-list” of features that he felt should be included in Java EE 7.
Red Hat, however, was not the only organization to have responded to Goncalves. Another group, consisting of engineers from Terracotta, Oracle and even Red Hat, has been working to update JSR-107, an older, once-dormant draft standard for a Java cache.
Despite it never being fully adopted in Java EE, JSR-107 has influenced the design of Java cache products from companies like Terracotta and Oracle. Now that work on that specification has started again, Terracotta is working on an implementation of JSR-107 for its flagship Ehcache software.
“So much work has already gone into JS-107. It seems unusual for someone to come in with a completely untested and unadopted product and try to make that the standard,” Terracotta’s Pandey said.
Red Hat personnel have shown an impatience for JS-107, however. “It’s been inactive for way too long, it is out of date, and the community is pretty jaded about it,” Red Hat engineer Manik Surtani wrote in a blog post.
Pandey criticized Infinispan for being difficult to deploy. “Data grids are fairly complex, used by a small niche of folks in high-end applications. The mainstream found it too difficult to use,” he said.
Infinispan is “only one architecture for doing a distributed system. What we’re focusing on with JSR-107 is simply doing the interfaces,” added Greg Luck, chief technology officer of Terracotta’s Ehcache, who is involved in the JSR-107 effort.
“The thing that is surprising is not that Red Hat wants to create a standard spec for data grids, but they are trying to replace JSR-107, when they well know the efforts that are currently under way,” Luck said.
Joab Jackson covers enterprise software and general technology breaking news for The IDG News Service. Follow Joab on Twitter at @Joab_Jackson. Joab’s e-mail address is Joab_Jackson@idg.com