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