3 ways in which Java modules will change the way you write code

This month we are looking at which version of Java you should be running. In our other articles, we look at Java 8 vs Java 11,  Which JDK should I use now?, Using JavaFX with Java 11 or Higher

One of the really exciting developments in Java over the last few years has been the final completion of Project Jigsaw – the modularization of Java. If you are using Java 9 or above this has the following huge benefits:-

1. Public access is no longer a global public

Ever since I started programming Java with version 1.0, using the public keyword to provide access to methods or objects in your packages was problematic. You ran the risk that users would take this as part of the API. With module files, you can now essentially have module public (we only allow access to this in certain specific other modules and hide it from public usage) and global public (we really do want this to be part of the API).

2. Dependencies no longer need to be hell

You know something is an issue when it has its own Wikipedia page! Module files can now specify what other Java libraries they need and which version. The user will not find issues because the wrong version has been loaded on the classpath somewhere. All those why does the software work on my machine but not yours discussions should now be a thing of the past!

3. You can now ignore large parts of the JDK you never use

In future years, software archaeologists may well look at the JDK to see what technologies used to be used in the distant past. Java has always maintained this backward compatibility and we still have such interesting relics such as CORBA and RMI. There are also lots of features in the JDK which are very useful but not needed in a specific project (desktop on a server, SQL if you are not using databases). The JLink tool allows you to create a custom JDK with just the parts of the JDK you need to use.

What about backwards compatibility?

Java includes a feature to create a multi-jar which will work on Java 8 and a later Java version. This allows you to start creating modular code which will work for developers still using Java 8.

Example of a module file

Here is the simple module file we include with our JDeli image library. It defines what other software is required (just java.desktop and java.base which is implicit).

Any public methods in the listed packages are part of the public API. There are lots of other public methods in the rest of the code but they are only for internal use and the user cannot see them.

module com.idrsolutions.jdeli {
    requires java.desktop;
    
    exports com.idrsolutions.image;
    exports com.idrsolutions.image.bmp;
    exports com.idrsolutions.image.dicom;
    exports com.idrsolutions.image.gif;
    exports com.idrsolutions.image.ico;
    exports com.idrsolutions.image.jpeg;
    exports com.idrsolutions.image.jpeg2000;
    exports com.idrsolutions.image.jpeglossless;
    exports com.idrsolutions.image.pdf;
    exports com.idrsolutions.image.png;
    exports com.idrsolutions.image.process;
    exports com.idrsolutions.image.psd;
    exports com.idrsolutions.image.scale;
    exports com.idrsolutions.image.sgi;
    exports com.idrsolutions.image.tiff;
    exports com.idrsolutions.image.utility;
    exports com.idrsolutions.image.webm;
    exports com.idrsolutions.image.wmf;
}

Summary

One of the aims in Java has always been to write readable and easily maintained code which will be usable for years to come by anyone on the team. Modularization is a significant move to maintaining this advantage.

Indeed, I think that modules are one of the most exciting features added to Java since it was first launched. What are your thoughts?

Our software libraries allow you to