Modularity and the Future of Java

With the fast approaching release of Java 9, I decided to delve into one of its main new features - the Java Platform Module System (JPMS) - curious to see whether this update will have as big of an impact on the way we program in Java as its predecessor.


Modularity is a method of splitting up reusable pieces of code into related packages and is generally considered a good practice across many programming fields, as it reduces a great deal of redundancy and vastly simplifies the process of updating and maintaining large codebases. To a certain extent, modularity is already employed in Java with libraries and packaging - but Java’s core code, its JRE and JDK, have always been one massive bundle of required resources regardless of actual usage.

The JPMS aims to solve this problem by splitting all of Java’s core code into an array of (as of the writing of this article, 95) modules. A project created in Java is then capable of importing any number of these modules necessary, while excluding all others - creating a much more simplified, streamlined package with all of the benefits thereof.

Efficiency and Reduction

One of the most immediately noticeable benefits of this change is the ability to customize a project’s build to contain only code absolutely necessary for that project - significantly decreasing package size and increasing performance. This in itself is enough to make Java 9 a worthwhile update, but the architecture of JPMS contains much more than just improvements in efficiency.

Encapsulation and Security

Another major feature of Java’s modularity is the requirement to explicitly declare dependencies in such a way that code is securely encapsulated. This is done in a two-step fashion: not only must a module declare that it requires another module, but the required module must declare that it is available for export. This is a large departure from the existing packaging structure, but provides a robuster level of security against potential attackers and reinforces the principle that only necessary code is available to and within each module, and access to code is implicitly denied unless otherwise configured.

Java 9

Modularity isn’t the only major feature to be included in Java 9, but it is the cornerstone of the update. Java 8 proved a dedication to efficiency by creating ways to considerably condense large chunks of code into much cleaner lines. Java 9 follows this example, but with a focus on streamlining the overall underlying architecture. This will undoubtedly prove a huge change - and challenge - in the future of Java development, further facilitating the necessity to create efficient, stable, and secure projects.

I, for one, am excited to get my hands on this new release, and curious to see how difficult (or easy) it will be migrating from one version to the next - especially with such large architectural changes on the horizon.

In short, Java 9 modularity aims to:

  • Split Java’s core code into modules - independent packages of reusable, related code.
  • Allow a project to declare dependencies based specifically on necessity (rather than requiring all of Java’s core code in the form of a JRE or JDK, regardless of usage, as is currently the case).
  • Force strong encapsulation by requiring explicit dependency declarations from both sides - a module must declare a requirement, and the requirement must declare its availability for exportation, or access to the code will fail.
  • Increased security with access to a module implicitly denied unless otherwise configured, making it more difficult for potential threats to use code in ways other than intended.
  • Decreased project size and increased maintainability with the ability to customize a project’s build to contain only necessary code, cutting down on superfluous dependencies.

You can read more about Java 9 and its features in preparation for the official release here.