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 >
