Proposal: #DefaultModule

[Paul Benedict]

Mark, I think adding a name is very elegant. Glad to see this. +1 :-)

PS: I think it's easier to explain to people "default" vs "unnamed" because
people are already familiar with default packages. Every Java programmer
knows default packages have no names. It's a no-brainier to teach that a
"default" module has no name too. Keeping the same terms should be desired,
I think. I don't know if David still is desiring the rename, but I am still
for it. Given that the new module description (in this email chain) takes
away the confusing issue of a named unnamed module, I can't see another
impediment in calling it the default module now. I would like the EG to
still consider it, but only after hearing other feedback first (especially
David, the author of the proposal).

Cheers,
Paul

On Wed, Jul 13, 2016 at 11:25 AM, David M. Lloyd <david.lloyd at redhat.com>
wrote:

> On 07/13/2016 09:32 AM, mark.reinhold at oracle.com wrote:
>
>> 2016/7/5 7:41:52 -0700, david.lloyd at redhat.com:
>>
>>> 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.
>>>
>>
>> The concept of unnamed modules has worked out pretty well so far.  The
>> analogy with unnamed packages, while imprecise, has made it fairly easy
>> to explain to people.  The fact that an unnamed module has no name is
>> not, as you correctly point out elsewhere, what keeps it from being a
>> candidate for resolution.  If these modules could have names, however,
>> then people would naturally ask why they can't participate in resolution,
>> and we'd have yet more explaining to do.
>>
>> I'm therefore reluctant to change unnamed modules into "default" modules,
>> so I suggest that we instead focus on your goal rather than a specific
>> potential solution.
>>
>> Your goal seems to be to enable module systems other than JPMS to place
>> their own diagnostic information in stack traces and certain exception
>> messages.  Such systems typically (always?) create a unique class loader
>> for each loaded module, and so in JPMS terms each such "external" module
>> would be represented by a class loader that loads all of its classes into
>> that loader's unnamed JPMS module.
>>
>> If this is correct then there's a simpler way to reach your goal: Enhance
>> class loaders to have optional names.  When the run-time system generates
>> a stack trace or an exception message that mentions a module name and
>> version, if present, then it could also insert the name of that module's
>> class loader, if present.  This would allow an external module system to
>> provide better diagnostics without having to change the JPMS design in a
>> fundamental way.
>>
>> Would that meet your needs?
>>
>
> I think that would probably work very well, and fits in nicely with the
> existing architecture of stack trace assembly as I understand it (since the
> class loader can be directly referenced from the Class, which is already
> present).  Thanks!
>
> --
> - DML
>