“The module system:Â a seat belt, not a jetpack”
I visited JavaOne (for the first time) in October this year with the main goal to get more information about Java 9 and the support for modularity which is more known as Project Jigsaw. Java 9 was initially targeted for September 2016, but when I listened and talked to others at JavaOne I realised that it would be hard to reach that target and hence it was no surprise when Mark Reynolds recently set the new target date to March 2017 in order to get everything in place.
This is not a post about Java 9 and how the new modularity support will be implemented and how to use it. It is more of a reflection in general and why we should us it. If you want to find out more about Jigsaw I suggest you to download the presentations at JavaOne Â or watch them. I can recommend (“Prepare for JDK 9”, “Introduction to Modular Development”, “Advanced Modular Development”, “Project Jigsaw: Under the Hood”, “Project Jigsaw Hack Session”).
Modularity is certainly not a new thing which Bert Edman began his talk “Building Modular Cloud Applications with OSGi” (I can recommend his book with the same name) where he refers to Dijskstra which addressed the need for “separation of concerns” in the 70s. This design pattern to let each module to have a single functional responsibility is well understood, but hard to achieve or at least to preserve over time. I can see that from the company I have been Chief Architect for the last years. One of the products was built with its own modularity system. The design goals where good, butÂ from the start the concept of concern were misunderstood. The modules were designed from a technical aspect instead of a functional concern aspect.
A module exposes some kind of interface (external) that reflects the concern and responsibility of the module. The implementation (internal) part implements the contract and hides from the outer world how this is implemented. Another useful concept/pattern that describes this is the Cohesion and Coupling where a well designed system should strive for Low Coupling between modules and High Cohesion within the modules. Easy to write, hard to achieve.
Each module defines it module definition in the module-info.java file. In the example above there are two different modules. One is declaring its dependency to another module (extenda.a -> extenda.b) and one module declaring its external API (package com.extenda.api). By declaring the modules in java files and not meta-inf files give for example compile time support. I am also fond of exporting packages and not single interfaces and classes as in OSGi. It makes it easier for the developer since it is easy to att the class/interface to the module file instead of just placing it in the exported package.
So far, there has been no java language support for modularity except for the package concept. The most well-known and proven module support is OSGi which has been both criticised and proven in production. I tried Apache Karaf a couple of years ago which at that time was easy to use and it seemed to work pretty well. I only made a small prototype and in the end we selected a non OSGi framework to implement the new integration product. But, I like the concept of OSGi.
Maven (and Gradle/Ivy) is also some kind of modularity system that is easy to understand and use.
So why do I want to start using modules? Modules will not solve everything, but I see three things that will help us:
Standard language support
OSGi and Jigsaw has a lot of similarities. As I see it OSGi has the pros of being more mature and proved in battle. If you need to switch modules during runtime you should go for OSGi.
WeÂ don’t have the need for switching of modules in runtime and still OSGi is not part of the standard of Java and as the product company I work for my role is to always try to use the standard as much as possible since the products lives for a long time. Selecting a GUI framework for a web or mobile client is not a fun thing since there is a new cool framework and language every month. Therefor we have selected as JavaFX as much as possible for our client where it is possible to use.
In the same way using an official language feature will make it more future proof in many aspects.
What we lack from our home grown modular system is the language and tooling support to get compile time support. We waste a lot of time to get the errors until runtime. Jigsaw will help us with that.
Explicit external API
Other products that we have don’t explicitly defined an external API and hence all classes and interfaces are part of the external API.
The products are meant to be customized for each customer where needed. The problem we face is that the developers tend to forget that we have the responsibility to avoid breaking backward compatibility. If we had explicitly defined what is external we could create rules that verifies this for every build. Another advantage of start using modules is to preserve the design of the concern of each current “module”.
Runtime images with JDK 9
The JDK has itself been refactored and modularised and for the first time deprecated classes will probably been unavailable to use in JDK 9 and 10. The modules are “packaged” in three different profiles (compact1, compact2 and compact3) which contains different number of modules. With this is mind and new tool to create my own runtime image with just the modules I need is a feature that we will use in the future. Embedding the JRE and other components such as the database will make the life easier for the company and our customers.
Even though Java 9 is not scheduled until Q1 2017 it is time to start design and implement for Jigsaw. Download the Jigsaw alpha release, design your modules and create your module-info.java files and setup a nightly build to verify your design from now on. Make sure you download the Jigsaw alpha JDK release and not the regular JDK 9 release.