Java 9: Why Modules?

What Are Modules?

The Java Module System, a.k.a. Project Jigsaw, is an effort to introduce a higher-level structural concept into Java. In a nutshell: Classes assemble into packages, and packages assemble into modules. Modules declare the other modules on which they depend, and in turn export packages for other modules to depend on.

Modules are a fundamental new concept going deep into the JDK, and have been under development for years. Jigsaw was originally planned for Java 7. As work began it became clear that this was a huge undertaking reaching deep into the internals of the JVM and the Java language itself. Yet, despite being slipped to Java 8 and then to Java 9, the need for it has only increased. Why do we need modules in Java? Why is Project Jigsaw such a big deal?

Why Modules?

Mark Reinhold, the Chief Architect of the Java Platform Group at Oracle, gave a keynote speech at Devoxx Belgium where he described the purpose of a module system and why it is so important.

There are many use cases that modules solve, but they all boil down to two primary pain points:

  1. Brittle, error-prone classpath (AKA JAR Hell)
  2. Monolithic JDK

Let’s look more at each of these.

Brittle Classpath

Have you ever seen a ClassNotFoundException? How about NoClassDefFoundError, NoSuchFieldError, or NoSuchMethodError? Maybe even a ClassCastException: “Cannot cast com.foo.Bar to com.foo.Bar”? All of these are the results of a brittle classpath. What that means is that ClassLoaders don’t have a good mechanism for distinguishing one loaded class from another class of the same name, or for isolating classes loaded by one ClassLoader from classes loaded by another.

From the Wikipedia entry on JAR Hell, problems from a brittle classpath arise from one of these situations:

  • Accidental presence of two different versions of a library installed on a system. This will not be considered an error by the system. Rather, the system will load classes from one or the other library. Adding the new library to the list of available libraries instead of replacing it may result in the application still behaving as though the old library is in use, which it may well be.
  • Multiple libraries or applications require different versions of library foo. If versions of library foo use the same class names, there is no way to load the versions of library foo with the same classloader.
  • The most complex JAR hell problems arise in circumstances that take advantage of the full complexity of the classloading system. A Java program is not required to use only a single “flat” classloader, but instead may be composed of several (potentially very many) nested, cooperating classloaders. Classes loaded by different classloaders may interact in complex ways not fully comprehended by a developer, leading to errors or bugs that are difficult to analyze, explain, and resolve

In some cases, build tools may help you detect some of these situations (such as incompatible dependency graphs). But the fact remains that tools will not prevent you from doing dangerous things, and they do not protect you from all of the situations described above.

Java Modules will provide reliable configuration and strong encapsulation. If you have incompatibilities, you will discover these at build time instead of some indeterminate time after your application has started running in production.

Monolithic JDK

The JDK has been big for years. At this point in 2016, the JDK is too big to fit comfortably on small devices, and we would really like it to be easy to use embedded devices and other devices on the Internet of Things.

Now you might say “But I run my software on a large server, we are not constrained by space.” However, even on large servers we want to run lots of VMs and optimize memory use. If every instance you have requires an extra 200MB of memory that it doesn’t need, that adds up across hundreds of instances, and those resources are something you pay for every second of every day. Additionally, with a monolithic JDK startup performance is slower because of loading unnecessary things. We would like to measure our startup time in milliseconds, not thousands of milliseconds.

Java Modules will allow us to break up the JDK into modules so that we only use what we need. We will be able to deploy modular runtime images that take less space and that start up faster.

Conclusion

The changes for Java 9 to support modules are far reaching, and it will take some work because we will have new language features and syntax to learn. But I think this will be worth it to make Java applications stronger, faster, and more reliable. In a subsequent post we will look more at the details of how modules work and how we can start to incorporate them into our own software.

What do you think? Have you had the problems that Jigsaw is trying to solve? Or are these non-issues for you?

Advertisements

Leave a comment

Filed under Java 9

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s