Do we actually need module names?

[mark.reinhold at oracle.com]

2015/9/28 9:56 -0700, peter.kriens at aqute.biz:
> 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.

I don't follow.  Humans already use names, without versions, for many
things in Java, and in programming environments more generally.

>                      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.  ...

Module descriptors, i.e., module-info.class files, are not intended to
contain all of the information that tools may require to compute
compile-time or run-time module paths.  They are not intended to replace
pom.xml files in Maven, or similar types of files in other build systems.
They are, rather, intended to contain just the information required by a
Java compiler or JVM to provide reliable configuration and strong
encapsulation, i.e., requires, exports, uses, and provides.

There is some unavoidable conceptual overlap here in the dependence
information (requires), but it should be straightforward for an IDE or
other tool to to relate module names to the artifact identifiers of the
build system being used, and to keep the dependences expressed in module
declarations in sync with those in artifact descriptions.

> 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.

Names based on content hashes certainly have their place, but they're not
suitable for human consumption.  I don't see how it makes sense for Java
modules not to have human-understandable names, but perhaps I'm missing
something here.

> 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.

The use of hashing to secure the use of qualified exports is part of the
proposal, though it's not yet fully implemented in the prototype.

> Obviously this leaves the dependency on the jre/jdk; this will be
> harder to specify as a digest.

Indeed it would.

- Mark