Do we actually need module names?

[Peter Kriens]

If a module could require package names instead of module names it would not be necessary to introduce a new orthogonal namespace to the code base.

If we take an application module path then this will represent a limited (max a few thousand, on average much less) set of modules. The current design already implies that in this set modules their exported packages must be unique, so there is no need to resolve multiple versions. It is therefore very almost no overhead to find a module by its exported packages instead of a module name. 

Since the Java bytecode already contains the reference to the exported packages it is straightforward to translate these references to a require package in the module definition. This will actually be much less work than developers maintaining a module namespace.

Just think of the advantages:

* No new error prone module namespace
* Automatic generation of module requirements
* No need for an awkward solution to module refactoring

About hashes, they have their place in the application artifact we discussed but I now thinks that using package requirements is a better solution.

Thanks, kind regards,
	
	Peter Kriens







> On 5 okt. 2015, at 20:53, mark.reinhold at oracle.com wrote:
> 
> 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