Proposal: #DefaultModule

[Paul Benedict]

Okay. Well I still think it's strange for the default module to have a
name. I'm pretty sure it's meant to be analogous to the default package
which has no name either. It's the lack of a name that keeps it out of
resolution. Though to your point, maybe it's not a name you're looking for,
per se, as it is dynamic metadata. What is a Module had a Properties or
Map<String,Object>? Your need sounds custom enough that you could stuff it
into attributes.

Cheers,
Paul

On Wed, Jul 6, 2016 at 12:22 PM, David M. Lloyd <david.lloyd at redhat.com>
wrote:

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