chapter two

2 Java modules

 

This chapter covers

  • Java’s platform modules
  • Changes to access control semantics
  • Writing modular applications
  • Multi-release Jars

As mentioned in Chapter 1, versions of Java, up to and including Java 9, were delivered according to a feature-driven release plan, often with a major new capability that defined or was strongly associated with the release.

For Java 9, this feature was Java Platform Modules (also known as JPMS, Jigsaw or just "modules"). This is a major enhancement and change to the Java platform that had been discussed for many years - it was originally conceived of as potentially shipping as a part of Java 7, back in 2009/10.

In this chapter, we will explain the reasons why modules are needed, as well as the new syntax used to articulate modularity concepts and how to use them in your applications. This will enable you to use JDK and third-party modules in your build as well as packaging apps or libraries as modules.

This change has profound implications for the architecture of applications, and modules have many benefits to modern projects that are concerned about things like: process footprint, startup cost and warmup time.

Modules can also help to solve the so-called "JAR Hell" problem that can plague Java applications with complex dependencies.

2.1 Setting the scene

2.1.1 Project Jigsaw

2.1.2 The module graph

2.1.3 Protecting the internals

2.1.4 New access control semantics

2.2 Basic modules syntax

2.2.1 Exporting and requiring

2.2.2 Transitivity

2.3 Loading modules

2.3.1 Platform modules

2.3.2 Application modules

2.3.3 Automatic modules

2.3.4 Unnamed module

2.4 Building a first modular app

2.4.1 Command-Line switches for modules

2.4.2 Executing a modular app

2.4.3 Modules and reflection

2.5 Architecting for modules

2.5.1 Split packages

2.5.2 Java 8 compact profiles

2.5.3 Multi-release JARs

2.6 Beyond modules

2.7 Summary