Modular Java

By the end of this lesson you'll write a module-info.java , control exactly what your code exposes with requires / exports / opens , build a plugin system with provides...with , and ship a slim custom runtime with jlink .

Learn Modular Java in our free Java course — a beginner-friendly interactive lesson with worked examples, a practice exercise and a quick reference.

Part of the free Java course at LearnCodingFast — hands-on lessons with examples you run in your browser, plus practice exercises and a quick quiz.

You should know Maven & Gradle (build tools package your modules), Interfaces (ServiceLoader is interface-driven), and ideally Reflection (which is what the opens directive controls).

💡 Analogy: Picture each module as an office building with a security desk. The lobby ( exports ) is where visitors are allowed — the public API. The back offices are private; no badge gets you in, no matter how "public" the door looks. requires is the list of other buildings you have a pass to enter . opens is handing a trusted contractor (a framework like Jackson) a master key for one floor so they can do maintenance (reflection) — but only at runtime. Before Java 9 there was no security desk at all: every public room in every building was open to everyone, which is exactly how apps ended up depending on someone else's plumbing.

That "no security desk" world was the classpath. JPMS adds the desk, and the rules live in one file per building: module-info.java .

A module is a named group of packages with an explicit contract: what it needs, and what it lets others use. You write that contract in module-info.java , placed at your source root. Each line is a directive :

The key idea: public stops meaning "anyone can use it." Now a class is reachable from outside only if its package is exports ed. Everything else is hidden — that's strong encapsulation .

On the old classpath , every JAR is dumped into one flat namespace and every public type is reachable. That's why projects accidentally call internal JDK classes like sun.misc.Unsafe and break on upgrade — nothing stops them.

On the module path , the JVM reads each module's module-info.java and enforces it. If a package isn't exported, you simply cannot import it, and a missing requires fails at startup rather than as a confusing runtime crash.

A service is an interface; a provider is a class that implements it. ServiceLoader finds every provider on the module path at runtime, so your app can be extended by dropping in a new JAR — no code changes, no if / switch .

💡 Analogy: Think of a wall socket standard . The socket (interface) defines the shape. Any appliance (provider module) that fits plugs in. Your app just asks "what's plugged in?" and uses whatever it finds.

The consumer declares uses Service , each provider declares provides Service with Impl , and ServiceLoader.load(Service.class) ties them together.

Fill in the three directives. Then check your answers against the // ✅ Expected comment at the bottom.

Wire a new provider into the plugin system from worked example 2 without touching the consumer.

You run modular code by naming the module and main class: java -p out -m com.myapp.app/com.myapp.app.Main . The -p flag is the module path; -m picks the entry point.

jlink goes further: it builds a custom runtime image containing only the JDK modules your app actually uses, plus your own modules and a launcher script. The result runs on a machine with no JDK installed and is a fraction of the size — ideal for containers and installers. Use jdeps first to discover exactly which modules you depend on.

Below is a real shell session: compile on the module path, run, then trim it down with jdeps + jlink .

You don't modularize everything in one go. The migration path is the automatic module : drop a plain JAR (no module-info.java ) onto the module path and JPMS treats it as a module that exports all its packages and can read every other module.

Its module name comes from the Automatic-Module-Name manifest entry if present, otherwise from the JAR filename. So you can write requires gson; today even though Gson isn't modular yet, modularize your own code first, and convert dependencies later as they publish real module descriptors.

No starter code this time — just an outline. Build the three modules, then prove a new provider works without touching the app.

You can now write a module-info.java , enforce strong encapsulation with exports / opens , build a ServiceLoader plugin system with provides...with , run on the module path, and ship a slim jlink runtime — migrating gradually via automatic modules.

Next up: Deployment — packaging, Docker images, and shipping Java apps to production.

Practice quiz

• Browse all free courses
• Cheat sheets & quizzes
• Coding dictionary