With the release of Java 7 Standard Edition programming language finally out of the way, it did not take long for discussions speculating on Java 8’s features to pop up. Members of the Java Community Process and those affiliated with Oracle have begun churning out ideas on what to include with the future release, and one area that seems to be of particular importance is that of prepping Java 8 for the cloud.
In order to maintain a timely release date, Oracle had to ship Java 7 without several advanced features that the company had planned for the platform. While those omissions may be a letdown, it is quite likely that such features could be included in Java 8. Mark Little, the senior director of engineering for Red Hat’s middleware business and Red Hat’s primary liaison for the Java Community Process, said, “Java 8 is supposed to set the scene for the cloud, for a wider deployment arena.”
According to Little, two key features will be necessary to give Java 8 capabilities for wide-scale cloud deployment. The first is the ability for the Java Virtual Machine (JVM) to run multiple applications in a safe manner, or multitenancy. The second is the restructuring of the Java Development Kit (JDK) into a set of interdependent modules that are cleanly defined, or modularity. “Modularity and true multitenancy within the JVM will be critical for 8 if Java will be dominant in the cloud,” he said.
Little believes that modularity is Red Hat’s most wanted feature for Java 8 for various reasons. It would give developers the ability to only use parts of the codebase that they truly need, giving them a more streamlined avenue to interact with Java. Since some deployments do not require all of Java’s core libraries, modularity would also decrease the size of most Java deployments. In addition, modularity would tackle the pesky developer problem that Little refers to as “classloader hell.” This nuisance occurs when a Java program accesses collections of frequently used routines, or Java Archives (JARs). An app may incorrectly use on JAR’s class when it really needs a different version of the class that sits in another JAR. The problem can also occur if an app uses a JAR that’s used by another program. Once the other program finishes, the JAR is removed, causing the initial program to terminate. Little said, “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.”
Project Jigsaw addressed the classloader hell issue and was planned for inclusion with Java 7. Unfortunately, it was removed from Java 7’s plans in 2010 to not affect the platform’s 2011 release date. Regardless, Project Jigsaw or the similar OSGi approach should see some involvement in the next Java release. “There will be some modularity present in Java SE 8,” said Little.
As mentioned, multitenancy is another integral feature for Java 8’s wide-scale cloud deployment. The fact that it enables the safe running of multiple applications from a JVM is a must for Java’s cloud computing, since more than one party could share the same infrastructure. Little said, “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.” He urged the need to give the JVM the ability to give each application its own memory space. Doing so would keep a rogue app from spilling over into another app’s memory space running in the same JVM.
As for Java 8’s availability, Oracle has not released any official timeline as of yet. However, a release prior to the end of 2012 seems likely if you go by the dates posted by the JCP. Little added, “We don't want to wait another four years or five years between 7 and 8.”