Unfortunately attributes cannot appear in stack traces, and there is
value in returning something meaningful for getName() in that module as
well.
Consider that OSGi modules (among other things) can never be Jigsaw
modules; at least it would be useful to allow them to have a clean
appearance in stack traces and have a meaningful result for getName().
Thanks to the possibility of multiple layers, it is already not
guaranteed that loading a module with a name found in getName() will
yield that module. Also consider that default modules actually do not
have a Layer at all.
Again it's *not* the lack of a name that keeps it out of resolution.
It's being outside of resolution that caused it to have no name - but
this is not a necessary condition for the existence of this module;
there *must* be some default in order for all classes to have a module
(even if they are loaded outside the module system). The class loader
should be allowed to choose the name of this default.
On 07/06/2016 12:32 PM, Paul Benedict wrote:
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.ll...@redhat.com
<mailto:david.ll...@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 <fo...@univ-mlv.fr
<mailto:fo...@univ-mlv.fr>
<mailto: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> <mailto:david.ll...@redhat.com
<mailto:david.ll...@redhat.com>>>
> À:jpms-spec-expe...@openjdk.java.net
<mailto:jpms-spec-expe...@openjdk.java.net>
<mailto: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>
<mailto: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
--
- DML
