Module System (JPMS)

ServiceLoader only creates a provider object when you actually reach it while iterating, not up front. Since Java 9, ServiceLoader.stream() gives a stream of Provider handles, each exposing type() so you can check the class and call get() to instantiate only the one(s) you want.

A .jmod file is a packaging format for a module that, unlike a JAR, can also carry native libraries, native commands, config files, and legal/header files. You create and inspect .jmod files with the jmod tool. They are used at link time (by jlink), not at application runtime.

jdeps analyzes your code to find its dependencies and can draft a module descriptor; jmod packages a module (including native code) into a .jmod; jlink links your modules and their dependencies into a small, self-contained runtime image. The chain breaks mainly on non-modular libraries and on dependencies resolved by reflection.

These command-line flags relax module rules without editing module-info. --add-exports lets you use a package that isn't exported; --add-opens grants deep reflection into a package; --add-modules forces a module into the graph even if nothing requires it; --add-reads lets one module read another it didn't declare. They are temporary bridges during migration.

Run jdeps --jdk-internals across all your code and dependency JARs to find usage of internal JDK APIs and their suggested replacements, then fix or replace those before upgrading. Because jdeps is static, also runtime-test, since reflective access to internals won't show up.

requires says your module depends on another. requires transitive also re-exports that dependency to anyone who depends on you, so they read it automatically. The set of who-can-read-whom is the readability graph. Designing these directives well keeps APIs clean and migration manageable.

Automatic modules read and export everything, so they give no real encapsulation and their derived names can be unstable. JPMS also forbids the same package being supplied by two modules (a split package), which legacy JARs often violate — that causes resolution failures you must resolve by merging or relocating packages.

Use the module path when you want enforced boundaries, a validated dependency graph, and small custom runtimes (jlink). Stay on the classpath when the ecosystem you depend on isn't modularized, reflection-heavy frameworks fight encapsulation, or the migration cost outweighs the benefit.

Export only the packages that form your public API; keep everything else internal. Open packages only for the specific reflection-based frameworks that truly need them, and qualify those opens to just those frameworks. The default should be closed.

Use ServiceLoader/SPI when you want zero-dependency, JDK-native plug-in discovery — third parties extend your library by dropping in a jar/module. Use a DI framework when you need rich lifecycle, scoping, and wiring of many beans inside one app. SPI is for open extension points; DI is for assembling your own application's objects.