If you have followed previous instalments, you will know we have used JDeps to create a multi-jar file version of our JPedal Java library. This allows it to support Java8 but offer support for Java modules if developers want to make use of this feature.
On Java 8, it works exactly as before. On Java 11 and above, it detects a module-info file and all the feature of project jigsaw work. We could have called this directory 9 and supported Java 9 and Java 10, but these were only short term releases and no-one should be using them.
JDeps generated a generic module-info file which has been edited to export just the correct API. There are lots of public classes used internally in JPedal, but they are no longer visible unless in the exported packages.
module com.idrsolutions.jpedal {
requires java.desktop;
requires java.logging;
requires javafx.swing;
requires javafx.controls;
exports com.idrsolutions.image;
exports com.idrsolutions.image.bmp;
exports com.idrsolutions.image.jpeg;
exports com.idrsolutions.image.jpeg2000;
exports com.idrsolutions.image.jpeglossless;
exports com.idrsolutions.image.png;
exports com.idrsolutions.image.scale;
exports com.idrsolutions.image.tiff;
exports com.idrsolutions.image.utility;
exports org.jpedal;
exports org.jpedal.examples;
exports org.jpedal.examples.acroform;
exports org.jpedal.examples.baseviewer;
exports org.jpedal.examples.easyintegration;
exports org.jpedal.examples.handlers;
exports org.jpedal.examples.images;
exports org.jpedal.examples.printing;
exports org.jpedal.examples.text;
exports org.jpedal.examples.viewer;
}Now that we have a multijar, JDeps could potentially see different versions for different versions of Java. the JDeps tool solves this by elegantly failing with a sensible message
Setting the –multi-release to different versions of Java shows some interesting results.
Java 10 (so no module file)
Java 13 (module file present for Java11, Java12 and Java13)
This is really neat because it allows us to test our jar configuration under lots of different configurations!