Java Modules

  • For modularising code for components and subsystems, Java package is not exactly the best choice. It requires code to be organised into name-spaces, domain names and folders, which is not the best way to compartmentalise code.

  • Then came jars. But that wasn’t much good except for zipping up packages of class files together.

  • In a multi-jar deployment, you cannot specify the dependencies between these jars. The Java compiler, nor the JVM has any such concept. Every public class is visible to all other classes.

  • These issues are actually not prohibitive, but in larger projects, it contributes to JAR hell!! At the most, you get a NoClassDefFoundError.

  • Java 9 introduced the Java Platform Module System (JPMS) to the language, bringing modularity primitives to all Java developers.

Graphing Theory

  • To understand the need for modularity and separation of concerns, the mathematical subject of Graphing Theory allows us to visualise and better appreciate what the problem is.

  • Graphing is prevalent in computing, - where a module is broken down into components and subsystems going top down - with dependency inversion where high level code always calls low-level code, which in turn have to implement interfaces, inverting the dependency upwards.

../../_images/DependencyGraph.png

Two system architectures for the same system depicted as graphs.

Nodes may represent JARs or classes in Java.

The goal of principles like seperation of concerns and dependency inversion are to disentangle the graph. If we ignore this, the architecture becomes a mess of code where nothing can be changed without potentially breaking something that seems unrelated. If we follow these principles, the architecture for the system becomes much better organised.

Key features of JPMS

The Java Platform Module System (JPMS) that was introduced in Java 9 (Sep 2017) provided modules which had the following characteristics:

  • A name. Preferably one that is globally unique.

  • Declarations of dependencies with other modules.

  • A clearly defined API of exported packages.