Java 8 Gears up for the Cloud
Now that Java 7 SE (Standard Edition) has officially been released, Oracle and members of the JCP (Java Community Process) have started mulling over what features to include in the next version of the programming language, Java SE 8. On the agenda for this new release: engineering Java for the cloud.
"Java 8 is supposed to set the scene for the cloud, for a wider deployment arena," said Mark Little, senior director of engineering for Red Hat's middleware business, as well as Red Hat's primary liaison for the JCP. Oracle left out many of the advanced features planned for Java 7 in order not to further delay the release, he noted. Those releases may very well be included in Java 8.
At least two of those features will prove instrumental in making the next version of Java ready for wide-scale cloud deployment, Little said. One is multitenancy, or the ability for the Java Virtual Machine (JVM) to safely run multiple applications. The other is modularity, or a reorganization of the JDK (Java Development Kit) into a set of cleanly defined though interdependent modules.
"Modularity and true multitenancy within the JVM will be critical for 8 if Java will be dominant in the cloud," Little said.
Modularity is what Red Hat would most like to see in Java 8, Little said. Modularity would cut the size of most Java deployments, because not all deployments need all of Java's core libraries. It would also help developers more easily interact with Java, allowing them to only use the parts they need rather than grapple with the entire codebase.
Modularity would also help with a developer problem that Little describes as "classloader hell."
Developers experience classloader hell when a Java program accesses multiple JARs (Java Archives), or collections of commonly used routines. An app may use a class from one JAR when it actually needs a different version of that class that resides in another JAR. Or it may use a JAR used by another program, and once that other program terminates, the JAR is removed, causing the first application to stop working.
"In order to have modules swapped in and out at will without screwing up the whole environment, you need to have support in the JVM as well," Little said.
One effort, Project Jigsaw, has been working on this goal. When Sun Microsystems controlled Java (Oracle purchased Sun in 2010), that company's engineers preferred Jigsaw over another approach, OSGi (Open Services Gateway initiative), overseen by the OSGI initiative.
Project Jigsaw was slated for Java 7, though it got pulled in 2010 in order to ship Java by 2011, Little said. Nonetheless, either the work from Jigsaw or OSGi should be folded into Java 8, Little predicted. "There will be some modularity present in Java SE 8," he said.
In addition to modularity, Java 8 may also feature multitenancy, or the ability to safely run multiple applications from one JVM.
Such a feature would be essential for Java to be used in cloud computing, where multiple parties may share the same infrastructure.
Today the Java Enterprise Edition offers a work-around for this problem, however. "If the JVM itself isn't offering multitenancy, then there is only so much we can do before the whole thing can potentially get screwed up by rogue tenants in the same JVM," Little said.
Little advocated adding to the JVM the ability to give each application its own memory space, or zone. By doing this, "a rogue app will not [spill over into] a memory space you saved for another app running in the same JVM," he said.
Little is not alone in cheering on this idea.
"Adding multitenancy to JVM is important," agreed Forrester Research analyst John Rymer. "Today, each vendor must come with its own way of virtualizing its application server."
Building multitenancy into the JVM would ease the training burden that comes with supporting each unique approach. It would cut back on vendor lock-in as well as "allow vendors to invest in robustness and performance more than base function," Rymer said.
Another feature that many have long championed for inclusion in Java is closures, or the ability to create a function within another function and have them share variables. Closures would be helpful in running Java more efficiently across multiple processor cores.
While Oracle chief Java architect Mark Reinhold has been enthusiastic about including closures within Java, he did not feel the proposed implementations were ready for Java 7. The fight will begin anew for closures' inclusion in Java 8.
"The work on closures looks like it will be a compatible, more restricted version to what we already have in Scala," boasted Martin Odersky, Scala creator and co-founder of Scala tools vendor Typesafe.
Beyond the technology itself, many are closely watching how Oracle shepherds Java 8 going forward.
Oracle has not yet established an official timeline for a Java 8 release, but members of the JCP seem eager to avoid another long interval before the next release, unofficially pegging the release by the end of 2012. "We don't want to wait another four years or five years between 7 and 8," Little said.
"At times I think Oracle speaks with multiple tongues," Little said. "Sometimes the Oracle people I talk with really want to do the right thing, not trying to run an open-source project like a closed-source project."
Other times, however, Little has found Oracle will conduct itself in a way that goes against these principles. He pointed to how in 2010 Oracle changed, without input, the governing bylaws for the OpenJDK project, which maintains an open-source version of the JDK. As a result, Red Hat lost its place on the steering committee, "despite the fact we were contributing so much code," Little said.
"We're involved with quite a few open-source projects. The whole way in which that way was handled was not very open source to us," Little said. Oracle declined to comment for this article.
In many ways, Java 8 will be the true test of how Oracle manages a complex open-source project, one with many contributors from so many competing interests.