Proposal: #DefaultModule

[David M. Lloyd]

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