Proposal: #DefaultModule

[Paul Benedict]

The only problem, I see, with renaming the "unnamed" to "default" module is
that it also changes the semantics. The unnnamed module has no name so it
cannot be depended upon by a named module. However, once you begin calling
it the "default" module and allow a name to be assigned, it no longer makes
sense for the current restrictions.

Is the purpose of #DefaultModule to also allow normal modules to explicitly
depend on the "default" module? Since it could have a name, I don't see why
it couldn't technically -- but it changes the design of the module system.

Cheers,
Paul

On Wed, Jul 6, 2016 at 11:48 AM, Remi Forax <forax at univ-mlv.fr> wrote:

> Hi David,
> Correct me if i'm wrong,
> it seems like the proposal to be able to specify how to find the name and
> the version of an automatic module (i.e.
> #CustomizableAutomaticModuleNameMapping) but for the default module.
> The idea is that an existing module systems will be able to provide a name
> and a version for the default module of the layers it controls.
>
> so this issue should be named #CustomizableDefaultModuleNameMapping and
> i'm fine with it
> (obviously the devil is in the detail, i.e. how to do implement that ?)
>
> and the name "default module" seems to be a better name that the unamed
> module.
> When naming something, avoid name that refers to a property and use name
> that refers to the concept said an old professor of me.
>
> Rémi
>
> ----- Mail original -----
> > De: "David M. Lloyd" <david.lloyd at redhat.com>
> > À: jpms-spec-experts at openjdk.java.net
> > Cc: "jigsaw-dev" <jigsaw-dev at openjdk.java.net>
> > Envoyé: Mardi 5 Juillet 2016 16:41:52
> > Objet: Proposal: #DefaultModule
> >
> > I propose that the concept of "unnamed module" be dropped in favor of
> > "default module".  The main difference is that the class loader (or
> > module finder or layer configuration or someone else) would be allowed
> > to (but not required to) assign a free-form name and version string to
> > this module.  This would allow existing module systems to bring their
> > module concept into some form of consonance with Jigsaw without
> > compromising any of the restrictions that Jigsaw-style modules have.
> >
> > Effecting this change would suggest the addition of an "isDefault()"
> > method on Module, possibly replacing "isNamed()" (which is arguably
> > already somewhat redundant with respect to getName()).  Also at some
> > stage, something would have to establish the default module name and
> > version strings, probably defaulting to the (current) null strings to
> > keep a stable status quo.
> >
> > --
> > - DML
> >
>