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 <fo...@univ-mlv.fr
<mailto:fo...@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.ll...@redhat.com
<mailto:david.ll...@redhat.com>>
> À:jpms-spec-expe...@openjdk.java.net
<mailto:jpms-spec-expe...@openjdk.java.net>
> Cc: "jigsaw-dev" <jigsaw-dev@openjdk.java.net
<mailto:jigsaw-dev@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
