JavaOne 2015 was the right time to dig into Java 9 JDK features

Java's Chief Architect, Mark Reinhold, offered one of the most exciting presentations during the 2015 JavaOne keynote talk on Sunday. He whetted the appetite of the audience for positive change with a look at how the Java community is pushing to resolve two ongoing pain points: JAR hell and the JDK monolith.

Java changes yet stays the same

Reinhold's presentation focused on why and how the Java language and platform have been altered over time. He pointed out that, on this 20^th anniversary, Java holds true to its original value of improving developer productivity with readability, simplicity, universality, and compatibility. Each update revolves around identifying a pain point and finding the missing abstraction that solves it.

According to Reinhold, Java is not interested in keeping up with the latest fashions or adding cool features just because other languages have them. In fact, Java doesn't like to appear to change. Mark's team feels most successful when improvements fit so perfectly that they seem to have been there from the beginning. From Generics in Java 5 to Lambdas in Java 8, new features are engineered to become part of the whole rather than to rebrand the language.

The upcoming changes build up by breaking down

Despite this tradition of low-key transformation, Reinhold's team is working on a solution for the upcoming Java SE 9 release that will have a profound and noticeable effect. Project Jigsaw has been in the works since 2008, making it one of the longest running projects to precede a major change. As with other long-awaited improvements, this one requires a great deal of thought to avoid creating more problems than it resolves. The pain points to be addressed are brittle and error-prone classpaths and the monolithic JDK.

Overthrowing the classpath system

As all Java developers know, the multiple libraries and long, complex classpaths that are an inevitable part of Java programming present an array of problems. While modern tools help resolve many conflicts and errors during a build, nasty surprises can still pop up during runtime. The fact that classpaths require a linear search of jar files verges on ridiculous, and causes issues with speed for even well-designed apps. According to Mark, the current classpath setup makes it difficult or impossible to answer the following questions:

• Are all classes are present?
• Are there any conflicts?
• Is it safe to change an internal API?

The proposed solution is to create modules that render these questions irrelevant. To accomplish this, first each module names the modules it needs to work (which ensures nothing is missing at runtime). Second, no modules can define the same package in the same class loader, ensuring there are no conflicts. Third, the descriptions will specify that packages are exported only for use by the modules that depend on them, making it safe to change internal APIs. According to Mark, this means the modules will be "correct by construction" with reliable configuration and strong encapsulation.

Disassembling the monolith at last

Modularization is also the proposed fix for the JDK monolith, making it ready for full functionality in today's cloud and mobile use cases. With client-side devices, there's often not enough memory to handle all the needs of the full JDK. In a similar way, replicating the entire JDK in a cloud environment comes with a high cost in terms of density. Being able to pick and choose the portions that are really needed for each environment will drive performance gains and minimize resource costs.

The other big change in modularizing the JDK will entail securing internal APIs using JEP 200. For critical, broadly used APIs, Java will provide some access until a supported alternative is available. But the veil of encapsulation will be drawn over those areas where developers really shouldn't be messing around anyway. Of course, the command-line flag will still provide access if it's absolutely essential.

Java life in the modular future

When these changes are implemented, Java is likely to become an even more robust solution for enterprises that want to stay current with technology best practices. By speeding up programming, minimizing errors, reducing resource expenditures, and enhancing security, modularization will help Java remain competitive as new programming languages vie for mindshare. The tried and true approach of solving known problems instead of being the first to do cool stuff is proving to be a smart path for the architecture of Java. Here's to twenty more years.