News Stay informed about the latest enterprise technology news and product updates.

Java 9 promises modularity and new value types

Modularity and new value types could come with Java 9. This could mean improved startup performance and easier programming of arrays.


News from JavaOne 2015

+ Show More

At the EclipseCon conference, Mark Reinhold, Java platform chief architect at Oracle, laid out the roadmap for Java 9, which could mean better modularity and new value types. Improved modularity could reduce app size and improve startup performance. New value types will make it easier to program arrays.

The principal feature of Java 9 is the introduction of a module system and the application of that to the platform. "This will help us deal with the fact that from the beginning the Java platform has been this huge monolithic thing," said Reinhold. This has created challenges and limitations to running on smaller devices and cloud environments even with the smaller SE versions of Java. Mobile devices are constrained by limited device hardware.

Cloud environments face constraints around startup time and the overhead that must run with each cloud VM or Docker instance. This can add up as organizations try to componentize application infrastructure using design patterns like microservices where the overhead of unused Java functionality takes up a higher percentage of resources. Also, because Java applications are compiled at runtime, all the unused libraries slow down the startup process for new instances. "You want to maximize application density," said Reinhold.

Improving size and startup times

'From the beginning the Java platform has been this huge monolithic thing.'

Mark Reinhold, chief architect, Java platform group at Oracle

The basic Java runtime environment (JRE) consumes about 55 megabytes of memory for a basic Linux ARM build. Java 8 introduced the notion of the compact platform which provides a subset of functionality with far less memory. The smallest Compact 1 profile consumes about 11 megabytes of memory, compared with 17 megabytes for Compact 2, and 30 megabytes for compact 3. Those smaller profiles help but are not flexible for the kinds of applications developers want to create today, said Reinhold.

On the performance side, a more compact and modular JRE will lead to better startup performance. Existing startup performance is frustrating, said Reinhold. This is not such a big deal for applications that run for long periods. But this can create critical delays when an organization wants to spin up new application instances to address peak loads. The longer the delays, the more an enterprise architect has to overprovision cloud services to maintain acceptable performance.

Enforcing good security as a forethought

Building out a modular architecture that can help maintain or improve security is one of the big challenges to making this work. Security has been one of Java's strengths when applications are implemented properly. Unfortunately, many developers seek to call internal classes that were never intended to be called by outside applications. Reinhold said that organizations need to enforce coding practices around only calling public classes. Developers should never write applications that call internal classes like "sun.*" and "*.internal.*"

Many libraries and applications are written to use these internal classes. This not only creates security problems, but is a problem for the team that maintains the JDK and limits this team's ability to evolve the internal classes. When some of these internals were modified to improve security, they broke working applications, so the Java team had to put them back, said Reinhold.

Building a better classpath

The final class of problems that the Java team would like to solve with Java 9 modularity is the classpath. This is a source of startup performance pain, since the Java compiler uses a linear search mechanism to find all the dependent modules. This also creates a problem with internal configurations. It can be difficult to configure applications, because missing components might not be discovered at runtime. In some cases, an application can be deployed with duplicate components when developers use two versions of a popular library in the classpath. Tools like Maven can help a bit but do not solve all the problems.

The long-term goal of the Java team is to eliminate the classpath. In essence this will make it possible for developers to assemble their applications from a box of Lego parts, rather than a monolithic thing. These parts could be assembled in different ways and organized so that developers would not leave any important pieces out of the final application.

Eike Stepper, an independent software architect in Germany, said the idea of modules is not particularly new, because the basic principles have been available in OSGi for some time. Only time and implementation use cases will prove out the importance of Java modularity for building real-world applications.

New types could improve performance

Another big piece that could become part of Java 9 is a new type for representing arrays of values. This will make it easier to specify multiple variable values without using pointers. If programmers want to specify a set of X,Y coordinates today, they need to use pointers, which consumes additional memory overhead and processing time.

The new variable type will allow coders to inline all the points in an X,Y array without losing the expressiveness of individual point value. This new type will make it possible to create arrays consisting of several correlated variable complex numbers. But it will become less efficient as the number of correlated variables grows. These new value types are being defined as part of Project Valhalla and Project Panama.

Developers at EclipseCon were excited but cautious about the potential for new types. "The new array types seem like they could make a lot of use cases easier but developers will have to be careful not to create new problems," said Ivan Inozemtsev, a lead software developer at Xored who leads the Eclipse RCP testing tool project.

More on this topic:

Will value types and structured arrays be Java 9's cap feather?

Java pro digs into trends in IoT, mobile, Java 9



Find more PRO+ content and other member only offers, here.

Conference Coverage

News from JavaOne 2015

Join the conversation


Send me notifications when other members comment.

By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy

Please create a username to comment.

I find it really interesting that those that maintain the JDK were forced to revert security changes due to people using internal libraries. On the other hand, as someone writing Java code, I know I have accidentally wrote code that used an internal library by accident because of IntelliJ's auto-importing. I fix that mistake as soon as I realized what I had done, but even if I did it intentionally, why can't the team make changes between major versions?  It isn't like you wouldn't do major testing (not to mention a recompile) when upgrading between Java versions?  Why is the Java team so stuck in the past?

As for making things more modular, I do hope this fixes some of the issues around JAR files and versioning.  While maven does help with that, it can still be rather painful.

What will really make things easier will be the new diagnostic commands planned, being able to print out structure lists, methods queued and constants etc.