Do we actually need module names?

[Peter Kriens]

This specification introduces a completely new namespace for modules. One of the lessons of the last decade has been that namespaces are very brittle and error prone. So a valid question seems to be: what do we get for this relatively high cost?
 
The only reason to use a name space is for humans. However, in the current proposal the names will likely not be used by humans since they lack a version. That is, the module-info.class contains too little information to be used by tooling as a source for the compile or runtime paths. It therefore seems inevitable that tools will generate this resource from their native metadata.

For example, in maven you define your dependencies in the pom and  a maven plugin will then have to assemble a module path. Since the group-id, artifact-id, classifier and version do not always fit in the restricted module name they already must be prepared to mangle these names.  And, yes I also expect that tools will hack the version in the module name; and every tool in its proprietary way. It is hard to envision any other way but tools generating the module-info.java. This is not a human editable file …

In the rest of the industry (git, docker) the direction is clearly in using naming based on content (e.g. SHA digests). The advantages of content addressing mechanisms over namespaces are enormous as many can testify. No duplicates, safe to cache, etc.

Once you accept that tooling is a given, it seems therefore to make more sense to bind the artifacts into a module path by their digest then to use brittle naming schemes. 

A nice demonstration is the discussion about modules masquerading as friends. In this description digests were already used limit the scope of the export-to concept. However, this mechanism is hinted at but not part of the proposal.

Obviously this leaves the dependency on the jre/jdk; this will be harder to specify as a digest. Well, one could look to .NET for inspiration :-)