Common to all solid architecture design is the notion of encapsulation, hiding the internals of a component and exposing a strict contract for consumers. This allows implementation changes to happen while giving strong guarantees about the behavior of other components. At DevNation 2016 Sander Mak and Paul Bakker from Luminis Technologies presented on the upcoming modularity features in Java 9 provided by the Jigsaw JSR which will introduce native mechanisms for enforcing strong encapsulation and service abstraction in the Java language. Java modules are a way of grouping java files and defining what services they provide and consume.
You might think "Hey, Java class files are typically distributed in JAR files, doesn't that count for modularity?" or maybe even "What about OSGi? Isn't that modularity for the JVM.". Although JAR files look like modules during compile time they get clumped together during runtime and there are no "fences" between the classes to hide implementation details. OSGi is a great modular framework but suffers from narrow adoption and adding modularity to the JDK will provide those same encapsulation benefits to many libraries and applications. Furthermore part of the Java 9 specification is targeting modularizing the JDK itself, which cannot be done with OSGi (a framework built on top of the JVM).
Stronger encapsulation means hiding whole packages that are implementation specific from consumers of your API and these principles apply to the JDK as well as other libraries. Currently implementation specific code (like classes from the packages com.sun.* and jdk.internal.* from the JDK) ideally should not be used but that doesn't stop developers. Those fortunate developers among us tasked with maintaining existing legacy systems might at this point question these fundamental changes and how they will impact existing code which could be using JDK internals. For now, the modularity refactoring in Java 9 will include exposing the internal unsafe classes to maintain backwards compatibility but will be provided with tooling to help migrate your legacy code. Automatic modules is one of these tools that will take your existing code and partially migrate it to modules. A plain JAR on the module path is an Automatic Module which will export everything and reads all other modules.
Theory is great, lets talk details. Say we are using a module that exposes some Java interfaces, like a good encapsulated library, how do we get a reference to an Implementation of the interface? Including the concrete type directly will necessitate a compile time visibility to the implementation which is the exact type of dependency we are trying to avoid with modularity. Enter the ServiceRegistry. The Java modules system utilizes a services loader which has been around for quite a while but is getting a face-lift for new usage in Java 9. Using just a reference to the interface a Java class can look up implementations via the ServiceLoader and then call any methods.
Iterator serviceImplentations = ServiceLoader.load(MyService.class);
The service loader will obey your Module metadata, so your module must be explicit about needing an implementation of the MyService interface:
module myApp {
requires thirdPartyAPI;
uses com.api.MyService
}
Likewise, part of the benefit of modularity lying in the requirement to enumerate your exposed services, your app will need to include a dependency on a module that provides an implementation:
module ThirdPartyProvider {
requires thirdPartyAPI;
provides com.api.MyService with myProvider.MyServiceImpl
}
Now, the service loader will be able to find the concrete implementation and you can actually Get Stuff Done. Modularization as a first class feature within the JVM, how cool! Look for all these features and more coming in Java 9!
