Do we actually need module names?

[Remi Forax]

The things is that we need a notion of 'meta-package' to not specified dependencies on something that change,
packages are added, packages (not exported, i hope) are removed, dependencies changes, module name is the things that are stable here.

Bytecodes contains the notion of public re-export, you can derive public required modules from them,
but not the notion of exported package, how to make the difference between com.foo.bar.api and com.foo.bar.internal ?

regards,
Rémi

----- Mail original -----
> De: "Peter Kriens" <peter.kriens at aqute.biz>
> À: "Mark Reinhold" <mark.reinhold at oracle.com>
> Cc: jpms-spec-experts at openjdk.java.net
> Envoyé: Lundi 12 Octobre 2015 18:48:07
> Objet: Re: Do we actually need module names?
> 
> 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
> 
>