Building modular applications in Java requires thoughtful design. The Java Platform Module System provides essential tools for creating maintainable systems. I’ve found these ten techniques instrumental in developing robust software.

Declaring modules starts with a module-info.java file. This file defines dependencies and exported packages. For instance:

module com.example.inventory {  
    requires com.example.persistence;  
    exports com.example.inventory.service;  
}  

This declaration states our inventory module needs the persistence module and exposes its service package. Clear boundaries prevent accidental coupling between components.

Service registration decouples implementations from consumers. Consider this logger module:

module com.example.logger {  
    provides com.example.Logger  
        with com.example.FileLogger;  
    exports com.example.logger.spi;  
}  

Here, we bind the Logger interface to FileLogger while exporting only the SPI package. This pattern enables pluggable implementations without exposing internal details.

Optional dependencies handle non-essential features gracefully:

module com.example.reporting {  
    requires transitive com.example.data;  
    requires static com.example.analytics;  
}  

The static keyword marks analytics as compile-time only. If unavailable at runtime, modules still function without it. I’ve used this for experimental features that shouldn’t break core functionality.

Controlled reflection maintains security while allowing framework access:

module com.example.webapp {  
    opens com.example.webapp.internal to org.framework;  
    exports com.example.webapp.api;  
}  

This selectively opens internal packages to specific frameworks. It’s safer than full openness, preventing unintended reflection access to sensitive areas.

Module layers enable dynamic plugin architectures:

ModuleLayer pluginLayer = ModuleLayer.boot().defineModulesWithOneLoader(  
    Configuration.resolve(  
        ModuleFinder.of(pluginDir),  
        List.of(ModuleLayer.boot()),  
        ModuleFinder.of()  
    ),  
    ClassLoader.getSystemClassLoader()  
);  

This creates an isolated layer for plugins. Each plugin gets its own classloader while sharing boot layer dependencies. I’ve implemented hot-reloading features using this technique.

Migrating legacy code often involves automatic modules:

module com.example.legacyapp {  
    requires legacy.jar;  
}  

The JVM derives a module name from the JAR filename. While transitional, this lets older libraries participate in modular designs until proper modules are created.

Aggregator modules simplify complex systems:

module com.example.allfeatures {  
    requires com.example.featureA;  
    requires com.example.featureB;  
    requires com.example.featureC;  
}  

This acts as a single entry point for related features. Clients depend on the aggregator rather than individual modules, reducing dependency lists significantly.

Multi-release JARs handle version-specific code elegantly:

module com.example.lib {  
    requires java.base;  
    exports com.example.lib.core;  
}  

Place Java 9+ module-info.class in META-INF/versions/9 while keeping legacy classes in main directories. This maintains backward compatibility while using modern features.

Resource encapsulation protects configuration files:

InputStream config = getClass().getResourceAsStream(  
    "/com/example/config.properties");  

Resources now follow module visibility rules. Only explicitly opened modules can access resources, preventing accidental file leakage.

Custom runtimes reduce deployment size:

jlink --module-path $JAVA_HOME/jmods:mods \  
      --add-modules com.example.app \  
      --output custom-runtime  

This generates minimal JREs containing only required modules. I’ve created 45MB production runtimes instead of full 300MB JREs, improving container efficiency.

These approaches work together to enforce boundaries. Explicit dependencies prevent hidden coupling. Service registration enables replaceable components. Resource control secures configurations. Together, they form a foundation for applications that scale gracefully while remaining understandable. Modular design isn’t just about organization—it’s about creating systems where changes stay localized and impacts remain predictable.