A module is a collection of packages. The package names in the module need not be related. For example, the module java.sqt contains packages java.sqt, javax.sqt, and javax.transaction.xa. Also, as you can see from this example, it is perfectly acceptable for the module name to be the same as a package name.
Just like a path name, a module name is made up of letters, digits, underscores, and periods. Also, just as with path names, there is no hierarchical relationship between modules. If you had a module com.horstmann and another module com.horstmann.corejava, they would be unrelated, as far as the module system is concerned.
When creating a module for use by others, it is important to ensure that its name is globally unique. It is expected that most module names will follow the “reverse domain name” convention, just like package names.
The easiest approach is to name a module after the top-level package that the module provides. For example, the SLF4J logging facade has a module org.slf4j with packages org.slf4j, org.stf4j.spi, org.stf4j.event, and org.stf4j.hetpers.
This convention prevents package name conflicts in modules. Any given package can only be placed in one module. If your module names are unique and your package names start with the module name, then your package names will also be unique.
You can use shorter module names for modules that are not meant to be used by other programmers, such as a module containing an application program. Just to show that it can be done, I will do the same in this chapter. Modules with what could plausibly be library code will have names such as com.horstmann.utit, and modules containing programs (with a class that has a main method) will have catchy names such as v2ch09.hettomod.
Source: Horstmann Cay S. (2019), Core Java. Volume II – Advanced Features, Pearson; 11th edition.