Proposal: #DefaultModule

[Paul Benedict]

All, please nix my suggestion. Alex kindly pointed out to me the JLS has
always called it "unnamed package", but I have always used the term
"default package" -- a likely colloquialism. I didn't invent the term but
many people call it that in conversation, message boards, etc. I don't know
the genesis of "default package" but I am glad he pointed out the correct
term to me. With my interest piqued, I loaded up Eclipse Neon for fun and
went to the Wizard to create a class. When I blanked out the package name,
the warning is, "The use of the default package is discouraged." I probably
have been using Eclipse for over 10 years and got accustomed to that
phrasing.

Cheers,
Paul

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

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