Proposal: #ModuleNameCharacters

[mark.reinhold at oracle.com]

2016/12/8 8:26:40 -0800, david.lloyd at redhat.com:
> 2016/12/7 15:40:17 -0800, mark.reinhold at oracle.com:
>> David -- Are these restrictions acceptable in your use cases, or if not
>> then at least tolerable?  I'm pretty sure I've never seen any of these
>> characters in Java EE module names, JAR file base names, Maven group or
>> artifact names, or the other examples you mentioned.
> 
> Breaking it down one by one...
> 
> ':' is going to break two things that I know of: modules generated from 
> Maven coordinates which have the syntax 
> <groupId>:<artifactId>:<classifier>, and modules in the JBoss Modules 
> static loader which have a slot component, using the syntax 
> "module-name:slot".
> 
> '@' might be OK to reserve; I can't think of any specific conflicts, 
> though we have allowed this character in the past.
> 
> '\' is a problem because in JBoss Modules uses that character to escape 
> ':' (particularly in the Maven coordinates case) to avoid mixing up the 
> slot name with the module name.  For a module named `foo\:bar:5`, the 
> static module loader would treat the name component as "foo:bar" and the 
> slot as "5", and locate the module accordingly, however the core system 
> does not treat '\' specially: the proper name of this module would be 
> `foo\:bar:5` according to the system, and that's the string you would 
> have to use to load the module by name.

Okay, so the obvious thing to do is define `\` as a quotation character
for itself, for `:`, and for `@`.  Then you can simply quote/dequote
wherever you interface with JPMS.

> '/' also may be a problem because within our container, we use file 
> names from the file system as the name of modules that come from the 
> file system.  This also causes a problem for '\' on Windows.  We could 
> possibly work out some kind of alternative in this case, with some 
> creative thinking.

I don't think we need to reserve `/`, as I said to Rémi.

As for `\`, I'm pretty sure that every version of Windows shipped this
century will accept `/` in pathnames as an alternative to `\`.

> Definitely in favor of forbidding non-printing code points 0x00 through 
> 0x1F, and probably also 0x80 through 0x9F (we probably don't want to go 
> any further down the Unicode rabbit hole than that though - at least, 
> not in the JVM - if we want to get out of here this side of 2020).

Validating any code points past 0x7f is problematic at the JVM level
since it's UTF-8, so you'd have to decode it.

- Mark