Proposal: #ModuleNameCharacters

[forax at univ-mlv.fr]

----- Mail original -----
> De: "mark reinhold" <mark.reinhold at oracle.com>
> À: "Remi Forax" <forax at univ-mlv.fr>
> Cc: "David M. Lloyd" <david.lloyd at redhat.com>, jpms-spec-experts at openjdk.java.net
> Envoyé: Mercredi 30 Novembre 2016 01:11:02
> Objet: Re: Proposal: #ModuleNameCharacters

> 2016/11/23 11:59:58 -0800, forax at univ-mlv.fr:
>> I agree with David, module names are just names so there should be
>> encoded as 'UTF8' kind of constant with no restriction.
>> 
>> Java (the language) module name format has more restrictions because
>> javac has to compile module-info.java files, but in the bytecode there
>> is no need to encode module name as 'internal name'.
>> 
>> When doing the JSR 292 spec, we (the EG) removed all the constraints
>> on class name, method name, etc that could be removed, in order to
>> ease the mapping of any languages on top of the VM.
> 
> Most, if not all, such constraints were removed long before JSR 292.
> For those that remain, John Rose proposed a fairly straightforward
> name-mangling scheme [1].
> 
>>                                                      If we want ease
>> the mapping between any existing and future module system to JPMS,
>> module name inside the class file format should be plain string
>> constant.
> 
> As I wrote in my reply to David, I'm open to lifting the traditional
> restrictions on the class-file representation of qualified names in the
> case of module names. 

Ok, cool.

> Given the weight of tradition and the past value
> of the existing constraints, however, I'd like to have a more compelling
> reason than "some future hypothetical module system might need this
> flexibility".

Existing constraints exist because a package name is a part of a qualified class name. There is no tradition for module names. Module names in the class file are not mixed with other constrained names, so i see no compelling reason to add arbitrary rules to try to restrict module names.  
Note that, JLS module names have to be parsed by the compiler, so for JLS module names, having the same constraints as any other qualified identifiers make sense, but here, we're talking about module names in the JVM spec, not in the JLS.

Now, the constant pool is typed and structured, if we want to have constraints on module names, in my opinion, we should introduce a new constant pool item to make it clear that module names are not plain names but specific names exactly like there is a Class constant pool item.

And with my ASM hat, having to add replace('.', '/') and replace('/', '.') at the right places is error prone, if we can avoid that is a big win in term of usability.


> 
> In trying to think about the future I do wonder if, today, we should
> reserve a character or two just in case we discover five or ten years
> from now that we need to add more structure to module names.  Should
> we set aside `:`, or perhaps some other character, just in case?

if we want structure, we will add another constant pool item. It's what valhalla does for parameterized types.

> 
> - Mark
> 
> 
> [1] https://blogs.oracle.com/jrose/entry/symbolic_freedom_in_the_vm

Rémi