Proposal: #ModuleNameCharacters

[mark.reinhold at oracle.com]

2016/12/5 16:12:06 -0800, david.lloyd at redhat.com:
> On 12/05/2016 05:05 PM, mark.reinhold at oracle.com wrote:
>> 2016/11/29 18:47:33 -0800, david.lloyd at redhat.com:
>>> ...
>>> 
>>> I'm just really confused at this line of justification.  Making module
>>> names be a qualified name is the very thing that I'm arguing against.
>>> Don't make any change to the restrictions on qualified names, and don't
>>> make module names be qualified names; that's all there is to it.
>> 
>> Okay, but in the language if an identifier is not a qualified name then
>> it cannot contain `.` characters, so using simple identifiers for module
>> names is a non-starter.
>> 
>> We could revise the JLS to introduce a brand-new kind of identifier,
>> just for module names, that allows `.` and maybe a few other additional
>> special characters, and encode these without using internal form in
>> `module-info.class` files.  This new kind of identifier would, however,
>> be something that every Java developer must learn about.
> 
> OK I think I see the disconnect here.  Here's what I'm reading from what 
> you're saying: The JLS says that names have to be one of: a qualified 
> names, an identifier, or some new invented thing that would have to be 
> added to the JLS, and if it's the last, that's a problem for new 
> developers and probably for a few other reasons as well.

Right.  Just about the last thing we want is additional complexity in the
source language.

> I have no disagreement with this point at all.

Okay, good.

>                                                 I'm only requesting that 
> the backing representation in the JVM/class file spec and/or 
> ModuleDescriptor.Builder side have no particular restrictions.  Can 
> these two concepts be decoupled somehow?  I recognize that this means 
> that javac-generated descriptors can never reference modules with 
> "invalid" (according to the JLS) names, but I don't see that as a 
> problem: this is solely for modules which are generated and referenced 
> by our container code from some other existing module scheme.

If you can live with that then yes, I think we can make something work.

> The reason I am opposed to using an obfuscation scheme in this case is 
> simple: it makes the diagnostic output and calls to get the name of your 
> current module have a confusing result, and this mechanism is one of 
> only two value propositions of Jigsaw that cannot currently be otherwise 
> achieved without special JDK support (the other being the new 
> security/encapsulation feature).  The .-to-/ mapping of internal names 
> is particularly irksome.

Understood.  I do think, though, that we should reserve a few characters
for future use.  I'll make a specific suggestion in my reply to Rémi in a
moment, since it's also related to an issue he raised about the structure
of class files.

- Mark