How should I name my Java 9 module?

Question

Suppose I have a library with groupId = org.abc and artifactId = myLibrary. What is the recommended name for the module name: myLibrary or org.abc.myLibrary? Is there any official guide for a naming scheme?

Answer 1

For a while there were two different opinions on your question but during the development of the module system, the community settled on the reverse DNS approach.

Unique Module Names - Reverse DNS

Here, the assumption is that module names should be globally unique. Given that goal, the most pragmatic way to get there follows the package naming strategy and reverse a domain name the maintainers are associated with. The State of the Module System says this:

Module names, like package names, must not conflict. The recommended way to name a module is to use the reverse-domain-name pattern that has long been recommended for naming packages.

Furthermore, Mark Reinhold writes:

Strongly recommend that all modules be named according to the reverse Internet domain-name convention. A module's name should correspond to the name of its principal exported API package, which should also follow that convention. If a module does not have such a package, or if for legacy reasons it must have a name that does not correspond to one of its exported packages, then its name should at least start with the reversed form of an Internet domain with which the author is associated.

This is pretty clear and shared by other Java experts like Stephen Colebourne.

Modules Are Greater Than Artifacts

For a while (beginning of 2016) there was another recommendation making the rounds. The JDK team stated that module names may not have to be unique after all "because modules are more abstract than the artifacts that define them". Mark Reinhold writes:

Choose module names that start with the name of your project or product. Module (and package) names that start with reversed domain names are less likely to conflict but they're unnecessarily verbose, they start with the least-important information (e.g., com, org, or net), and they don't read well after exogenous changes such as open-source donations or corporate acquisitions (e.g., com.sun.*).

The reversed domain-name approach was sensible in the early days of Java, before we had development tools sophisticated enough to help us deal with the occasional conflict. We have such tools now, so going forward the superior readability of short module and package names that start with project or product names is preferable to the onerous verbosity of those that start with reversed domain names.

Also, having module names that do not include a domain would allow exchanging that module against another implementation as long as it has the same name (and implements the same public API of course).

In the mail lined above, Reinhold documents his change of opinion:

Some people may prefer shorter, project-oriented names, and those can be fine to use in limited projects that will never, ever see the light of day outside of a single organization. If you create a module that has even a small chance of being open-sourced in the future, however, then the safest course is to choose a reverse-DNS name for it at the start.

Summary

The jury is in and everybody who made his or her opinion public agrees on reverse DNS like for packages.

Answer 2

I think we got an "official" answer from Mark Reinhold:

Strongly recommend that all modules be named according to the reverse Internet domain-name convention. A module's name should correspond to the name of its principal exported API package, which should also follow that convention. If a module does not have such a package, or if for legacy reasons it must have a name that does not correspond to one of its exported packages, then its name should at least start with the reversed form of an Internet domain with which the author is associated.