With version 9 of Java SE, Oracle introduced modules as a result of Project Jigsaw. Here we offer some considerations for existing projects.
Why break up Java?
A smaller Java core offers better security as less code means fewer bugs. A smaller core should also run easier on embedded devices. Modules therefore promise an answer to the discontinuition of the Java embedded platform.
What to know going forward
Java 8 shipped with an monolithic collection of 210 packages for software development. Java 9 breaks these packages into 26 modules, all or some of which can be included in a JVM installation.
Java 9 offers support for logging, Swing, and other functionality through modules, since not all feasible applications use them.
Two examples of major modules:
- java.base could be considered the new ‘core’ Java. It contains packages which will be found across all Java applications.
- java.se.ee could be considered the opposite of ‘core’ Java: it contains packages deprecated and marked for future removal. If you happen to use classes from this module, consider using more modern alternatives
The work on modularisation also produced a nice side effect: The Java 9 API documentation is finally fully searchable.
What is a module?
A set of packages. Each set is defined by a manifest file.
Will my pre-Java 9 code stop working?
As of Java 9, there exists a module path in addition to the class path.
If existing classes are left on the class path, and containing code does not use reflection, then said classes should continue to work as expected. If code does make use of reflection, there are numerous implications and upgrading to Java 9 should be assessed more thoroughly. To name one example, the ‘setAccessible()’ method to override access modifiers will stop serving this purpose in Java 9.
Once code is moved to the module path, Java expects packages to be collected as modules via aforementioned manifest files. If no manifest file exists for a given package, Java will add it to a default module called ‘unnamed module’. This should not be left as is, because named modules do not have access to the unnamed module.
There are implications regarding accessibility when code is added to modules: only packages that are exported by a module via its manifest file are accessible outside of the module. In other words, any packages that are not exported via a module’s manifest will be private to the module – including fields or methods marked as ‘public’.
As a result, Java 9 has somewhat altered the meaning of the keyword ‘public’.
