book

The Java Module System

Name: The Java Module System
Author: Nicolai Parlog
ISBN: 9781617294280

by Nicolai Parlog

July 2019

Intermediate to advanced

440 pages

13h 56m

English

Manning Publications

Read now

Unlock full access

The Java Module System
Copyright
dedication
contents
front matter
forewordprefaceacknowledgmentsabout this bookWho should read this bookHow this book is organized: a roadmapWatch out for theseAbout the codeliveBook discussion forumabout the authorabout the cover illustration
Part 1. Hello, modules
1 First piece of the puzzle
1.1 What is modularity all about?1.1.1 Visualizing software as graphs1.1.2 The impact of design principles1.1.3 What modularity is all about1.2 Module erasure before Java 91.3 Complications before Java 91.3.1 Unexpressed dependencies between JARs1.3.2 Shadowing classes with the same name1.3.3 Conflicts between different versions of the same project1.3.4 Complex class loading1.3.5 Weak encapsulation across JARs1.3.6 Security checks have to be handcrafted1.3.7 Poor startup performance1.3.8 Rigid Java runtime1.4 Bird’s-eye view of the module system1.4.1 Everything is a module1.4.2 Your first module1.4.3 The module system in action1.4.4 Your non-modular project will be fine—mostly1.5 Goals of the module system1.5.1 Reliable configuration: Leaving no JAR behind1.5.2 Strong encapsulation: Making module-internal code inaccessible1.5.3 Automated security and improved maintainability1.5.4 Improved startup performance1.5.5 Scalable Java platform1.5.6 Non-goals1.6 Skills, old and new1.6.1 What you’ll learn1.6.2 What you should knowSummary
2 Anatomy of a modular application
2.1 Introducing ServiceMonitor2.2 Modularizing ServiceMonitor2.3 Cutting ServiceMonitor into modules2.4 Laying out files in a directory structure2.5 Declaring and describing modules2.5.1 Declaring dependencies on other modules2.5.2 Defining a module’s public API2.5.3 Visualizing ServiceMonitor with the module graph2.6 Compiling and packaging modules2.7 Running ServiceMonitor2.8 Extending a modular code base2.9 Post mortem: Effects of the module system2.9.1 What the module system does for you2.9.2 What else the module system can do for you2.9.3 Allowing optional dependenciesSummary
3 Defining modules and their properties
3.1 Modules: The building blocks of modular applications3.1.1 Java modules (JMODs), shipped with the JDK3.1.2 Modular JARs: Home-grown modules3.1.3 Module declarations: Defining a module’s properties3.1.4 The many types of modules3.2 Readability: Connecting the pieces3.2.1 Achieving reliable configuration3.2.2 Experimenting with unreliable configurations3.3 Accessibility: Defining public APIs3.3.1 Achieving strong encapsulation3.3.2 Encapsulating transitive dependencies3.3.3 Encapsulation skirmishes3.4 The module path: Letting Java know about modules3.4.1 Module resolution: Analyzing and verifying an application’s structure3.4.2 Module graph: Representation of an application’s structure3.4.3 Adding modules to the graph3.4.4 Adding edges to the graph3.4.5 Accessibility is an ongoing effortSummary
4 Building modules from source to JAR
4.1 Organizing your project in a directory structure4.1.1 New proposal—new convention?4.1.2 Established directory structure4.1.3 The place for module declarations4.2 Compiling a single module4.2.1 Compiling modular code4.2.2 Modular or non-modular?4.3 Compiling multiple modules4.3.1 The naive approach4.3.2 The module source path: Informing the compiler about the project structure4.3.3 The asterisk as a token for the module name4.3.4 Multiple module source path entries4.3.5 Setting the initial module4.3.6 Is it worth it?4.4 Compiler options4.5 Packaging a modular JAR4.5.1 Quick recap of jar4.5.2 Analyzing a JAR4.5.3 Defining an entry point4.5.4 Archiver optionsSummary

5 Running and debugging modular applications
5.1 Launching the JVM with modules5.1.1 Specifying the main class5.1.2 If the initial module and main module aren’t the same5.1.3 Passing parameters to the application5.2 Loading resources from modules5.2.1 Resource loading before Java 95.2.2 Resource loading on Java 9 and later5.2.3 Loading package resources across module boundaries5.3 Debugging modules and modular applications5.3.1 Analyzing individual modules5.3.2 Validating sets of modules5.3.3 Validating a module graph5.3.4 Listing observable modules and dependencies5.3.5 Excluding modules during resolution5.3.6 Observing the module system with log messages5.4 Java Virtual Machine optionsSummary
Part 2. Adapting real-world projects
6 Compatibility challenges when moving to Java 9 or later
6.1 Working with JEE modules6.1.1 Why are the JEE modules special?6.1.2 Manually resolving JEE modules6.1.3 Dropping in third-party implementations of JEE modules6.2 Casting to URLClassLoader6.2.1 Application class loaders, then and now6.2.2 Getting by without URLClassLoader6.2.3 Finding troublesome casts6.3 Updated run-time image directory layout6.4 Selecting, replacing, and extending the platform6.4.1 No more compact profiles6.4.2 Extension mechanism removed6.4.3 Endorsed standards override mechanism removed6.4.4 Some boot class path options removed6.4.5 No compilation for Java 56.4.6 JRE version selection removed6.5 Little things that make big things fail6.5.1 New version strings6.5.2 Tool exodus6.5.3 The littlest things6.5.4 New deprecations in Java 9, 10, and 11Summary
7 Recurring challenges when running on Java 9 or later
7.1 Encapsulation of internal APIs7.1.1 Internal APIs under the microscope7.1.2 Analyzing dependencies with JDeps7.1.3 Compiling against internal APIs7.1.4 Executing against internal APIs7.1.5 Compiler and JVM options for accessing internal APIs7.2 Mending split packages7.2.1 What’s the problem with split packages?7.2.2 The effects of split packages7.2.3 Many ways to handle split packages7.2.4 Patching modules: Last resort for handling split packages7.2.5 Finding split packages with JDeps7.2.6 A note on dependency version conflictsSummary
8 Incremental modularization of existing projects
8.1 Why incremental modularization is an option8.1.1 If every JAR had to be modular …8.1.2 Mixing and matching plain JARs with modules8.1.3 Technical underpinnings of incremental modularization8.2 The unnamed module, aka the class path8.2.1 The chaos of the class path, captured by the unnamed module8.2.2 Module resolution for the unnamed module8.2.3 Depending on the unnamed module8.3 Automatic modules: Plain JARs on the module path8.3.1 Automatic module names: Small detail, big impact8.3.2 Module resolution for automatic modules8.3.3 All in on automatic modules?8.3.4 Depending on automatic modulesSummary
9 Migration and modularization strategies
9.1 Migration strategies9.1.1 Preparatory updates9.1.2 Estimating the effort9.1.3 Continuously build on Java 9+9.1.4 Thoughts on command-line options9.2 Modularization strategies9.2.1 Bottom-up modularization: If all project dependencies are modular9.2.2 Top-down modularization: If an application can’t wait for its dependencies9.2.3 Inside-out modularization: If a project is in the middle of the stack9.2.4 Applying these strategies within a project9.3 Making JARs modular9.3.1 Open modules as an intermediate step9.3.2 Generating module declarations with JDeps9.3.3 Hacking third-party JARs9.3.4 Publishing modular JARs for Java 8 and olderSummary
Part 3. Advanced module system features
10 Using services to decouple modules
10.1 Exploring the need for services10.2 Services in the Java Platform Module System10.2.1 Using, providing, and consuming services10.2.2 Module resolution for services10.3 Designing services well10.3.1 Types that can be services10.3.2 Using factories as services10.3.3 Isolating consumers from global state10.3.4 Organizing services, consumers, and providers into modules10.3.5 Using services to break cyclic dependencies10.3.6 Declaring services across different Java versions10.4 Accessing services with the ServiceLoader API10.4.1 Loading and accessing services10.4.2 Idiosyncrasies of loading servicesSummary
11 Refining dependencies and APIs
11.1 Implied readability: Passing on dependencies11.1.1 Exposing a module’s dependencies11.1.2 The transitive modifier: Implying readability on a dependency11.1.3 When to use implied readability11.1.4 When to rely on implied readability11.1.5 Refactoring modules with implied readability11.1.6 Refactoring modules by merging them11.2 Optional dependencies11.2.1 The conundrum of reliable configuration11.2.2 The static modifier: Marking dependencies as optional11.2.3 Module resolution of optional dependencies11.2.4 Coding against optional dependencies11.3 Qualified exports: Limiting accessibility to specific modules11.3.1 Exposing internal APIs11.3.2 Exporting packages to modules11.3.3 When to use qualified exports11.3.4 Exporting packages on the command lineSummary
12 Reflection in a modular world
12.1 Why exports directives aren’t a good fit for reflection12.1.1 Breaking into non-modular code12.1.2 Forcing the publication of internal types12.1.3 Qualified exports create coupling to specific modules12.1.4 No support for deep reflection12.2 Open packages and modules: Designed for the reflection use case12.2.1 Opening packages to run-time access12.2.2 Opening packages for specific modules12.2.3 Exporting vs. opening packages12.2.4 Opening modules: Reflection closeout12.3 Reflecting over modules12.3.1 Updating reflecting code for modules (or not)12.3.2 Using variable handles instead of reflection12.3.3 Analyzing module properties with reflection12.3.4 Modifying module properties with reflection12.3.5 Forwarding open packages12.4 Dynamically creating module graphs with layers12.4.1 What are layers?12.4.2 Analyzing layers12.4.3 Creating module layersSummary
13 Module versions: What’s possible and what’s not
13.1 The lack of version support in the JPMS13.1.1 No support for multiple versions13.1.2 No support for version selection13.1.3 What the future may bring13.2 Recording version information13.2.1 Recording versions while building modules13.2.2 Accessing module versions13.3 Running multiple versions of a module in separate layers13.3.1 Why you need a starter to spin up additional layers13.3.2 Spinning up layers for your application, Apache Twill, and Cassandra Java DriverSummary
14 Customizing runtime images with jlink
14.1 Creating custom runtime images14.1.1 Getting started with jlink14.1.2 Image content and structure14.1.3 Including services in runtime images14.1.4 Right-sizing images with jlink and jdeps14.2 Creating self-contained application images14.2.1 Including application modules in images14.2.2 Generating a native launcher for your application14.2.3 Security, performance, and stability14.3 Generating images across operating systems14.4 Using jlink plugins to optimize images14.4.1 Plugins for jlink14.4.2 Reducing image size14.4.3 Improving run-time performance14.5 Options for jlinkSummary
15 Putting the pieces together
15.1 Adding bells and whistles to ServiceMonitor15.1.1 Diversified dependencies15.1.2 Reduced visibility15.1.3 Decoupled with services15.1.4 Loads code at run time with layers15.1.5 Handles dependencies on plain JARs15.2 Tips for a modular application15.2.1 Modular or not?15.2.2 The ideal module15.2.3 Take care of your module declarations15.2.4 Breaking code by editing module declarations15.3 The technology landscape15.3.1 Maven, Gradle, and other build tools15.3.2 OSGi15.3.3 Microservices15.4 Thoughts on a modular ecosystemSummary
Appendix A. Class-path recap
A.1 Using the class path to load application JARsA.2 The class path since Java 9
Appendix B. High-level introduction to the reflection API
B.1 Fundamental types and methodsB.2 Breaking into APIs with setAccessibleB.3 Annotations mark code for reflection
Appendix C. Observing the JVM with unified logging
C.1 What is unified logging?C.2 Defining which messages should be shownC.3 Defining where messages should goC.4 Defining what messages should sayC.5 Configuring the entire logging pipeline
Appendix D. Analyzing a project’s dependencies with JDeps
D.1 Getting to know JDepsD.2 Including dependencies in the analysisD.3 Configuring JDeps’ outputD.4 Drilling deeper into your project’s dependenciesD.5 JDeps understands modules
Appendix E. Targeting multiple Java versions with multi-release JARs
E.1 Creating a multi-release JARE.2 Internal workings of MR-JARsE.3 Usage recommendationsE.3.1 Organizing the source codeE.3.2 Organizing the bytecodeE.3.3 When to use MR-JARs
Index
Lists of Figures, Tables and Listings
List of IllustrationsList of TablesList of Listings

Content preview from The Java Module System

Appendix E. Targeting multiple Java versions with multi-release JARs

It’s never easy to decide which Java version to require for your project. On the one hand, you want to give users the freedom of choice, so it would be nice to support several major versions, not just the newest one. On the other hand, you’re dying to use the newest language features and APIs. From Java 9 on, there’s a new JVM feature, multi-release JARs (MR-JARs), that helps you reconcile these opposing forces—at least, under some circumstances.

MR-JARs allow you to ship bytecode for different Java versions in the same artifact. You can then rely on the JVM to load the classes that you compiled for the most recent version it supports. Starting with a project that runs successfully ...

Become an O’Reilly member and get unlimited access to this title plus top books and audiobooks from O’Reilly and nearly 200 top publishers, thousands of courses curated by job role, 150+ live events each month,
and much more.

Read now

Unlock full access

More than 5,000 organizations count on O’Reilly

O’Reilly covers everything we've got, with content to help us build a world-class technology community, upgrade the capabilities and competencies of our teams, and improve overall team performance as well as their engagement.

Julian F.

Head of Cybersecurity

I wanted to learn C and C++, but it didn't click for me until I picked up an O'Reilly book. When I went on the O’Reilly platform, I was astonished to find all the books there, plus live events and sandboxes so you could play around with the technology.

Addison B.

Field Engineer

I’ve been on the O’Reilly platform for more than eight years. I use a couple of learning platforms, but I'm on O'Reilly more than anybody else. When you're there, you start learning. I'm never disappointed.

Amir M.

Data Platform Tech Lead

I'm always learning. So when I got on to O'Reilly, I was like a kid in a candy store. There are playlists. There are answers. There's on-demand training. It's worth its weight in gold, in terms of what it allows me to do.

Mark W.

Embedded Software Engineer

Up and Running with The Java Platform Module System (JPMS)

Publisher Resources

ISBN: 9781617294280Publisher Support Publisher Website Errata Page

Cloud Computing

Data Engineering

Data Science

AI & ML

Programming Languages

Software Architecture

IT/Ops

Security

Design

Business

Soft Skills

The Java Module System

by Nicolai Parlog

Appendix E. Targeting multiple Java versions with multi-release JARs

Become an O’Reilly member and get unlimited access to this title plus top books and audiobooks from O’Reilly and nearly 200 top publishers, thousands of courses curated by job role, 150+ live events each month,
and much more.