Proposal: #ModuleNameCharacters

[mark.reinhold at oracle.com]

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

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?

- Mark


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