Proposal: #DefaultModule
David M. Lloyd
david.lloyd at redhat.com
Thu Jul 7 19:44:35 UTC 2016
Not always. For example in the very common situation of existing module
systems where there is one module per class loader, if that module is
the default module (which BTW allows these module systems to retain
their existing resolution and delegation logic), it is certain that the
module will correspond to a single named entity if not a single artifact
as well.
On 07/07/2016 02:20 PM, Paul Benedict wrote:
> Clearly the unnamed/default module is an aggregation of many artifacts.
> I still don't find the unnamed/default module name useful, but the
> artifact enmeshed in the aggregate is. Not only should the stack trace
> provide this info, but there should be an API for it too. WDYT?
>
> Cheers,
> Paul
>
> On Wed, Jul 6, 2016 at 6:05 PM, Peter Firmstone
> <peter.firmstone at zeus.net.au <mailto:peter.firmstone at zeus.net.au>> wrote:
>
> Hmm, be useful for debugging.
>
> Peter.
>
> Sent from my Samsung device.
> ---- Original message ----
> From: David M. Lloyd <david.lloyd at redhat.com
> <mailto:david.lloyd at redhat.com>>
> Sent: 07/07/2016 03:40:22 am
> To: Paul Benedict <pbenedict at apache.org <mailto:pbenedict at apache.org>>
> Cc: jigsaw-dev <jigsaw-dev at openjdk.java.net
> <mailto:jigsaw-dev at openjdk.java.net>>; Java Platform Module System
> (JSR 376) Expert Group Observers
> <jpms-spec-observers at openjdk.java.net
> <mailto:jpms-spec-observers at openjdk.java.net>>
> Subject: Re: Proposal: #DefaultModule
>
> 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.lloyd at redhat.com <mailto:david.lloyd at redhat.com>
> > <mailto:david.lloyd at redhat.com <mailto: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>
> > <mailto:forax at univ-mlv.fr <mailto:forax at univ-mlv.fr>>
> > <mailto:forax at univ-mlv.fr
> <mailto:forax at univ-mlv.fr> <mailto: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>
> > <mailto:david.lloyd at redhat.com
> <mailto:david.lloyd at redhat.com>> <mailto:david.lloyd at redhat.com
> <mailto:david.lloyd at redhat.com>
> > <mailto: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>
> > <mailto:jpms-spec-experts at openjdk.java.net
> <mailto:jpms-spec-experts at openjdk.java.net>>
> > <mailto:jpms-spec-experts at openjdk.java.net
> <mailto:jpms-spec-experts at openjdk.java.net>
> > <mailto: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>
> > <mailto:jigsaw-dev at openjdk.java.net <mailto:jigsaw-dev at openjdk.java.net>>
> > <mailto:jigsaw-dev at openjdk.java.net <mailto:jigsaw-dev at openjdk.java.net>
> > <mailto: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
> >
> >
>
> --
> - DML
>
>
--
- DML
More information about the jpms-spec-observers
mailing list