"At JavaOne I asked a question about the naming standards for modules
given that we have automatic modules.
The scenario is as follows:
- an open source module foo that depends on Google guava
- guava has not yet been modularised
- guava is provided by jar file guava-19.0.jar and used as an automatic module
- foo declares "requires guava", where "guava" is a module name
derived from the jar file name
At some later time, guava is modularised, but chooses the sensible
module name "com.google.guava". Now, the module foo (released as open
source to maven central) has the wrong module name for guava.
Given this scenario, the Jigsaw team suggested that the correct module
name for guava is "guava". (The only alternative strategy at the
moment would be for open source projects published to maven central to
*never* declare requires on an automatic module).
I, and others, have expressed concern about a naming strategy for
modules that is not based on the reverse domain name strategy, eg
com.google or org.joda. It seems common to me that companies will have
modules that have the same name as publicly available modules in maven
central. The migration problem described above also seems overly
restrictive.
In addition, there are related problems to do with projects that fork
but want to retain the same name (maybe not desirable, but GutHub
forking is common).
Proposal
-------------
- a new concept *group name* should be introduced above module name
- the combination groupName:moduleName should always match the maven
group:artifact coordinates
- messaging in this way to the community will avoid migration issues
as the standard is already in use and accepted
- in module-info.java, the user must always specify both the group and
module name
- the requires clause may specify or omit the group name but always
has the module name
- best practice would be to include the group name to ensure reliable
configuration
- when depending on automatic modules, the group name would be omitted
- if omitted, the group name is inferred by the system from the
available modules on the module path
- automatic modules are in the unamed group
With this setup, the migration problem outlined above disappears. The
fully qualified name of guava would be "com.google.guava:guava", as
per maven naming standards [1]. Anybody who had depended on the
automatic module for guava using "requires guava" would still work (in
all except edge cases).
This would look for a module named "guava" in any group (likely to be
an automatic module). If found in two groups, the system fails to
start:
module com.mycompany:foo-utils {
requires guava;
}
This would look for a module named "guava" in group "com.google.guava:
module com.mycompany:foo-utils {
requires com.google.guava:guava;
}
This relates to #ModuleNameSyntax, in that the module name will be
more distinct - either with a colon, or being the short form. Ideally,
the convention would be for the module name to use dashes, not dots.
Thus, Joda-Beans would be "org.joda:joda-beans" when fully qualified.
Given the widespread adoption of maven, the combination of
group:artifact is very well known and accepted. It makes sense for
Java to adopt the convention.
(In fact, the way this is defined, it should be possible for Maven
Central / JCenter to run an automated job that adds a "weak module"
definition to all existing jars, using the maven coordinates as the
name. Whether this desirable to actually is debatable, but the fact
that it could be done strikes me as a good sign for migration.)
Stephen
[1]
http://search.maven.org/#search%7Cgav%7C1%7Cg%3A%22com.google.guava%22%20AND%20a%3A%22guava%22
