Hmm, be useful for debugging. Peter.
Sent from my Samsung device. Include original message ---- Original message ---- From: David M. Lloyd <david.ll...@redhat.com> Sent: 07/07/2016 03:40:22 am To: Paul Benedict <pbened...@apache.org> Cc: jigsaw-dev <jigsaw-dev@openjdk.java.net>; Java Platform Module System (JSR 376) Expert Group Observers <jpms-spec-observ...@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.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
