Proposal: #DefaultModule

[mark.reinhold at oracle.com]

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?

- Mark