Chapter 5 ■ a Java primer: introduCtion to Java ConCepts and prinCiplesThe Properties of Java Modules: Explicit, Automatic, or Unnamed
There are three ways to create Java modules: explicitly, implicitly, and anonymously. An Explicit Module
is created on purpose by the developer by specifying a module-info.java file that defines what other
modules and packages will be in the explicit module. The explicit module defines requires:inputs (needed
API packages) and exports:outputs (published packages). Exported packages are visible to the Java
environment and can thus be executed. Only requires (input or read packages) packages specified in the
module definition file can be accessed (utilized) by that module. I will show you the format for this definition
a bit later during this section of the chapter.
The Java 9 environment can also create an Implicit Module, which is also known as an Automatic
Module, if the developer has not supplied a module-info.java file and if it finds a JAR file on a module-path
that does not contain a module-info.java definition file, so the Java 9 environment automatically creates an
implicit module for the JAR file’s contents. In this case, it will automatically export all packages needed, require
(input or read) all modules needed, and include any unnamed modules as well, which we will cover next.
Finally, the Java 9 environment may also create an Unnamed Module by adding classes on a classpath
that are not in JAR files and do not have developer-supplied module-info.java files. This allows the Java 9
environment to accommodate older Java 6 through 8 projects by making them into Unnamed Modules so
that they will still function in the Java 9 environment even though they were created in earlier versions of
Java where module-info.java did not yet exist. An explicit module cannot require an unnamed module,
meaning developers of older versions of their Java software must create a module-info.java definition file to
bring their software into the Java 9 modularity realm.
If an application’s main classes are in the unnamed module, all default modules will be loaded to make
sure that the Java 9 application can function, and the benefits of modularity (data footprint reduction of the
distribution) will be lost. If you do optimally define a module-info.java file with the minimum packages
needed to run your Pro Java 9 Game, the javapackager utility will be able to produce a bundled application
for you with only the needed modules.
An Example of a Java 9 Module Hierarchy: JavaFX Modules
Since JavaFX was the first API that Oracle modularized and the native Java multimedia API that we will
need to use to create Pro Java 9 Games, it makes sense to use this as the example of how modules work,
which at the same time will show us how JavaFX is modularized and which JavaFX modules we could need
to “require” (input) for our own Java 9 module definition file. With Java 9 modules, JavaFX can be linked
directly into the JDK “image,” and there will be no need to reference an external JFXRT.JAR file. Third-party
JARs such as JFXSWT.JAR would become automatic modules. This JFXSWT.JAR will be renamed JAVAFX-
SWT.JAR for Java 9 so that when the automatic module derives its name, using the JAR file, it will become
JAVAFX.SWT.
The Java 9 Runtime Environment (JRE) contains seven JavaFX modules that you can “require” in your
own game module as needed. The fewer of these you require, the more optimized your data and memory
footprint would be for your game, and the more system resources will be available to your game processing
requirements.
Table 5-6 shows you the new JavaFX module hierarchy, which modules (base and graphics) are
required for any JavaFX usage, and which of the nonbase and nongraphics JavaFX modules require the other
JavaFX modules.