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> 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> > > À: jpms-spec-expe...@openjdk.java.net > > Cc: "jigsaw-dev" <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 > > >