Proposal: #DefaultModule

[David M. Lloyd]

No, the intent is that default modules are still outside of resolution 
altogether. Being unnamed isn't what puts the module outside the system; 
it's just that you have to *have* one outside the system in order to 
ensure that all classes have a Module instance, so I think we ought to 
be able to put a name and version on it (ideally free-form, not subject 
to the restrictions of a layer which otherwise has no control over this 
module anyway).

I don't want to change the design of the module system to accommodate 
this change, which is basically just allowing two fields to be filled in.

On 07/06/2016 12:10 PM, Paul Benedict wrote:
> 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
> <mailto: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 <mailto:david.lloyd at redhat.com>>
>     > À:jpms-spec-experts at openjdk.java.net
>     <mailto:jpms-spec-experts at openjdk.java.net>
>     > Cc: "jigsaw-dev" <jigsaw-dev at openjdk.java.net <mailto: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
>     >
>
>

-- 
- DML