Proposal: #DefaultModule

[Paul Benedict]

Err.. I meant "new class loader name". Ignore "new module description" --
didn't mean that. That's a typo.

Cheers,
Paul

On Wed, Jul 13, 2016 at 12:03 PM, Paul Benedict <pbenedict at apache.org>
wrote:

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