Modules

Copyright © Seán Kennedy

 Modules

Java 11 (1Z0-819)

Copyright © Seán Kennedy

 Modules

• Modules, introduced in Java 9, provide an extra layer of

encapsulation by enabling us to group related packages.

• From a high-level, modules enable us to specify well-

defined boundaries/dependencies in our code base.

• As a developer, you can specify which packages are

accessible outside the module and also the module
dependencies (the other modules that the module itself
depends upon).

Copyright © Seán Kennedy

 Why Modules?

• Improved access control:

• in addition to private, package-private, protected and public
now we have the ability to restrict packages to certain other
packages.

• Improved large-scale structure of applications:

• boundaries/dependencies in your code base.
• hide implementation details.
• improved decoupling.

Copyright © Seán Kennedy

 Why Modules?
• Reduced build sizes:
• as Java itself is now modularised, developers can specify
which of the Java API modules are required for their custom
applications; this results in smaller application sizes (a
consideration for memory-constrained devices).

• Earlier detection of missing code:

• prior to modules, missing classes/JAR files might only be
realised at runtime, when the class/JAR file was being used
for the first time.
• as modules specify their dependencies - in a fully modular
environment, the Java VM can check the whole dependency
graph when it starts up; thus, any missing modules would be
spotted much earlier. 5

Copyright © Seán Kennedy

 Modular Application

Farm Application

farm.owner Modules
farm.animals farm.count

farm.vet farm.sale

Copyright © Seán Kennedy

 Structure of a Module

farm.animals Module

farm farm.cattle module-info.java Packages

Cattle.java
Animal.java
Cow.java

Copyright © Seán Kennedy

 Modules
• By default, all classes in the packages in a module are
strongly encapsulated i.e. no other module can use these
classes, even if they are public classes.

• Package names and module names live in separate

namespaces i.e. you can have the same identifiers without
any conflict (name clash).

• A module contains one or more packages plus a

module-info.java file.

Copyright © Seán Kennedy

 Modules

• When compiling a module, it is more convenient to use

“module directories” as otherwise we would have to list all
the .java source files (including module-info.java).

• If you use a module directory, then the name of the module

directory must match the name of the module in the
module-info.java file.

• Place the module-info.java file in the root of the source tree

of the module you are describing.

Copyright © Seán Kennedy

Copyright © Seán Kennedy
 javac (compiler) flags

Listing all the source files: javac –d {dir} {all the java source files, including module-info.java}
Module directory(ies): javac –d {dir} –m {module_name}, {module_name} --module-source-path {src_dir}
Dependencies to other --module-path or –p
custom (possibly 3rd party)
modules:
Examples: javac -d out src/com/farm/Main.java src/module-info.java
javac -d out -m TestModuleFarm --module-source-path src
javac -d out --module TestModuleFarm --module-source-path src
javac –d {dir} –m {module_name} --module-source-path {src_dir} –p {dir e.g. “mods”}

Short Version Long Version

-m --module
-p --module-path
11

Copyright © Seán Kennedy

 java flags

java –p {module_path} –m {module}/{fully qualified main class}

Example: java -p out -m TestModuleFarm/com.farm.Main

Example: java --module-path out --module TestModuleFarm/com.farm.Main

Short Version Long Version Comment

-m --module -
-p --module-path The “classpath” for modules.

12

Copyright © Seán Kennedy

 Flags Recap

Command Flags Question flags answer

javac -d {dir} where to put the class files?
-m {module_name} what is the name of the module?
--module {module_name}
--module-source-path {src_dir} where is the module source code?
-p {dir e.g. “mods”} where are the custom modules we need (if any) ?
--module-path {dir e.g. “mods”}
Example: javac -d out -m TestModuleFarm --module-source-path src

java -p {module_path} where is the module?

--module-path {module_path}
-m {module}/{fully qualified main class} what is the name of the module?
--module {module}/{fully qualified main class}
Example: java -p out -m TestModuleFarm/com.farm.Main
13

Copyright © Seán Kennedy

 TestModuleFarm
Listing all source files

Copyright © Seán Kennedy

 TestModuleFarm2
Module Directory

Copyright © Seán Kennedy

 Dependencies between Modules

• As stated earlier, by default, all classes in the packages in a

module are strongly encapsulated i.e. no other module can
use these classes, even if they are public classes.

• If you want a package to be visible outside the module then

“export” it in the module-info.java file. The keyword exports
is used.

• If a module “depends” on another module, the keyword

requires is used.

16

Copyright © Seán Kennedy

 Dependencies between Modules

• All modules implicitly depend on the java.base module.

• the module exports the java.lang package (String, Object)

• Remember:
• you export (exports) a package
• you depend (requires) on a module

• The requires keyword between modules forms a dependency

graph.

17

Copyright © Seán Kennedy

 Dependencies between Modules

farm.stock.sale farm.stock.count

Copyright © Seán Kennedy

 1. Run SellThem example.
2. Jar version.

Copyright © Seán Kennedy

 opens

• Frameworks such as Spring and Hibernate, frequently

require access to our code at runtime via “reflection”.
• Class.forName(“farm.stock.sale.SellThem”).newInstance();

• Via reflection, calling code can override access control and

as a result of this power, you must clearly state that you allow
this type of access.

• Thus we want our types to be strongly encapsulated at

compile-time but provide runtime access via reflection.
The keyword opens provides this.
20

Copyright © Seán Kennedy

 opens
• In your module-info.java file you state:
• opens packageName;
• opens packageName to moduleName;

• A module itself can be open. This automatically opens all

packages inside the module.

21

Copyright © Seán Kennedy

 requires

farm.vet farm.owner

farm.animals

22

Copyright © Seán Kennedy

 requires transitive

farm.vet farm.owner

farm.animals
Note: The following is an error:

23

Copyright © Seán Kennedy

 Operations on a Module
• Packaging a module
• creating and executing a modular JAR (Java ARchives).

• Describing a module (java and jar).

• jdeps – discovering the dependencies in the module.

• jmod
• native libraries
• not executable
• intended for use with the jlink tool to build a custom native
image.
24

Copyright © Seán Kennedy

 Services
• Modules are tightly coupled due to the use of requires,
exports and the knowledge and creation of specific types.

• Services enable the decoupling of modules.

• Rather than modules directly coupling to other modules,

there is now a middle layer, the service registry which
abstracts the consumers from the producers.

• The service (interface) contract, which is hosted by the

registry, is what binds the consumers and producers together.
25

Copyright © Seán Kennedy

 farm.owner
farm.vet

farm.animals

26

Copyright © Seán Kennedy

 farm.vet farm.owner

farm.neighbour

farm.inspector farm.hired_hand

farm.spouse

farm.family_member

27

Copyright © Seán Kennedy

 farm.owner

provides
farm.vet

farm.neighbour

uses Registry provides

Service Contract

owner.api

Copyright © Seán Kennedy

 OwnerService example

Copyright © Seán Kennedy

 softdrink.small

softdrink.customer

softdrink.medium

Registry

softdrink.large

Service Contract
softdrink.extralarge
softdrink.api

Copyright © Seán Kennedy

 Types of Modules
• There are 3 types of modules:
• Named modules – contain a module-info file and appear on the
module path, not the classpath i.e. --module-path as opposed
to --class-path.
• Unnamed modules – non-modular JAR’s i.e. no module-info
file (if present, it is ignored) and appear on the classpath.
• think pre-modules i.e. the way Java worked before modules were
introduced.
• classpath code can read module path code but not vice vearsa.
• Automatic modules – non-modular JAR’s (typically from a
3rd party) that are on the module path
• Java automatically creates named modules for them by either:
• Automatic-Module-Name property in MANIFEST.MF
• otherwise, a set of naming rules are applied
31

Copyright © Seán Kennedy

 Automatic Modules
• Required when a modular application encounters a
non-modular JAR on the module path.

• Rules for naming them:

• Automatic-Module-Name property in MANIFEST.MF
• otherwise, the following rules apply (e.g. text-utils-1.0.jar):
• extension is dropped (text-utils-1.0)
• version information at end of file is dropped (text-utils)
• replace characters (other than letters/numbers) with dots
(text.utils)
• replace any sequence of dots with single dots
• remove single dots from beginning and end

32

Copyright © Seán Kennedy

 Automatic Modules
• All the packages in the automatic module are exported.

• The modular application (which is using the automatic

module), will need to state that it requires the automatic
module in its module-info file. This is why the naming rules
are important.

33

Copyright © Seán Kennedy

 Migration Strategies
• What if you want to migrate your classpath-based applications
to modules?

• There are 2 strategies that you can follow:

• Bottom-up
• Top-down

Bottom-up Top-down
application.jar

utils.jar other.jar

data-storage.jar services.jar
34

Copyright © Seán Kennedy

 Bottom-up
• Turning JAR files on the classpath into modules that we can
put on the module path.

• Algorithm:
1. Start at the “leaf” nodes i.e. nodes that have no dependencies
other than the JDK.
2. Create a module-info.java file for the JAR. Name the module.
Ensure all packages required by other (higher-level) JAR’s are
exported using the exports directive. In addition, all modules this
JAR depends upon must have requires directives.
3. Once migrated, this newly named module moves from the
classpath to the module path.
4. Repeat with the next lowest JAR until you finally have
modularised the top level JAR i.e. you are done.
35

Copyright © Seán Kennedy

 Bottom-up – using jdeps
• jdeps can be used to automatically generate the
module-info.java file

• So, rather than having to analyse all the code to check for all
dependencies, jdeps can do that for you.

Careful! All packages will be exported.

36

Copyright © Seán Kennedy

 Bottom-up
• The bottom-up approach yields benefits when all the modules
are modularised and the top-level root module is complete.

• An issue arises with the bottom-up approach when there are

external JAR’s that we do not have control over and are not
modularised yet.

• Do we wait for the external JAR developers to migrate the

unnamed modules or do we try to maintain the module
descriptors ourselves? Neither option is ideal.

• Constrained by the weakest link in the set of dependencies.

37

Copyright © Seán Kennedy

 Top-down
• Proceeds in a top-down fashion from the root.

• Uses automatic modules - where a modular application

encounters a non-modular JAR file on the module path and a
module is generated for it automatically .

• Thus, we can simply move the unaltered external non-modular

(i.e. unnamed) module/JAR file from the classpath to the module
path; where it will be converted to an automatic module.

• All we need to know is what name Java will give the automatic
module and modify our dependencies (requires) accordingly.
38

Copyright © Seán Kennedy

 Top-down
other-external-utils.jar

unnamed unnamed
external-utils.jar some-application.jar

classpath

module-path
external.utils some.application
automatic named

39

Copyright © Seán Kennedy

 Modules

Java 11 (1Z0-819)

40

Copyright © Seán Kennedy