We’re nearing the end of our journey through the Java module system—starting from the modular JDK, all the way through creating your own modules and migrating existing code to modules. On the one hand, there’s a lot of new functionality around modules to take in. On the other hand, Java modules simply encourage tried-and-true best practices around modular development.
Using modules for new code is recommended except for the smallest of applications. Applying strong encapsulation and managing explicit dependencies from the start lays a solid foundation for maintainable systems. It also unlocks new capabilities such as creating a custom runtime image with jlink.
Entering the modular future of Java requires adherence to the principles of modularity.
When your existing applications have a modular design, the transition will be smooth.
Many people already use multimodule Maven or Gradle builds for their applications.
Often these existing module boundaries map naturally to Java modules.
In some cases, the
ServiceLoader mechanism offered by the JDK is a good alternative to using a full-blown dependency injection framework.
However, when your applications are anything but modular, the transition will be challenging.
You saw in earlier chapters that it is certainly possible to migrate existing applications to modules. When their design is lacking in modularity, ...