When using Java 9 module system, you need to pay attention to naming specifications, packaging control, dependency management, automatic module usage and layered design. It is recommended to adopt a reverse domain name style such as com.example.mymodule to avoid conflicts and enhance recognition; try to be clear in semantics, do not use vague or duplicate names, and do not start with numbers or special characters. Exports and requirements should be clearly defined inside the module, only necessary packages should be exported, dependencies should be explicitly declared, and maintainability should be improved and coupling should be prevented. Use automatic modules with caution, and give priority to modular libraries. If necessary, confirm the stability of their module name and avoid mapping conflicts. The correct --module-path should be configured in the build tool instead of the old classpath. The module structure should be reasonably layered, such as placing the interface, implementation, and main program in different modules to improve project clarity and scalability. Plan the module boundaries in advance to ensure convenient long-term maintenance.

The module system (Jigsaw) introduced in Java 9 makes the project structure clearer and the dependency management clearer, but there are actually some things to do with it well. This article does not talk about principles, but only practical suggestions.

Module naming should be standardized, so don't save trouble

Although the module name is just a string, it will affect the maintainability of the entire project. It is recommended to use reverse domain name styles uniformly, such as com.example.mymodule , which can avoid naming conflicts and facilitate identification of attribution.

Some people like to call core or utils directly, which is OK in small projects, but it is easy to get confused when collaborating with large teams or multiple people. If you have to use a short name, at least prefix it, for example com.example.core .

• Try to be semantic and clear
• Avoid duplicate or blurred module names
• Don't start with numbers or strange characters

Clearly exports and requirements, don't expose them all

One of the biggest benefits of a module system is its packaging capability. Don't exports all packages for the sake of convenience. Only exposing the parts that really need to be visible to the outside, while the rest remains hidden inside can effectively prevent misuse and excessive coupling.

At the same time, requires must be written clearly, especially when calling across modules. If you rely on a module, be sure to declare it explicitly and do not expect the JVM to handle it automatically.

For example:

 module com.example.service {
    require com.example.api;
    exports com.example.service.impl;
}

In the above code:

• Only impl package is exported, and other packages are not visible to the public by default.
• It explicitly relies on the com.example.api module

In this way, others will know what your module depends on and what services you provide.

Be careful when using automatic modules

Some old projects or third-party libraries are not modular yet, so Java allows you to introduce them through automatic modules . Although convenient, this approach is risky: the JVM automatically infers module names, which can lead to conflicts or difficult to trace.

suggestion:

• Try to use modular libraries
• If you have to use automatic module, it is best to confirm whether the automatically inferred module name is stable
• Avoid multiple libraries mapping to the same automatic module name

Also, when using JPMS in build tools such as Maven or Gradle, be careful to configure the correct module path ( --module-path ) instead of the old classpath ( -classpath ).

Layered design of module structure, don't make it a whole pot of porridge

The module system does not allow you to tear a bunch of files at will, but encourages you to do reasonable layering. For example, a common approach is to separate the interface and implementation into different modules, like this:

• com.example.api : defines interface, public type
• com.example.service : implement specific logic
• com.example.app : Main program entry, combining various modules

This structure is clear and easy to maintain, and is also convenient for testing and replacement implementation.

If you make a big module from the beginning, it will be very troublesome to split it later. Planning the module boundaries in advance is very important for long-term maintenance.

Basically that's it. The module system itself is not complicated, but when it is really implemented in the project, you still have to pay attention to the details, otherwise it will easily become "it seems to have used modules, but it is actually the same as before."

The above is the detailed content of Java Module System (Jigsaw) Best Practices. For more information, please follow other related articles on the PHP Chinese website!