Proposal: #ModuleNameCharacters

[David M. Lloyd]

On 12/08/2016 08:00 PM, mark.reinhold at oracle.com wrote:
> 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.

That should be fine, I think.

>> '/' 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 `\`.

Yeah, but in any event allowing \ as an escape solves everything, and 
limiting the number of specials prevents it from becoming too unwieldy, 
so I'm satisfied with that.

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

Fair enough.

Thanks!
-- 
- DML