Proposal: #ModuleNameCharacters

mark.reinhold at oracle.com mark.reinhold at oracle.com
Mon Dec 5 23:05:56 UTC 2016


2016/11/29 18:47:33 -0800, david.lloyd at redhat.com:
> On 11/29/2016 06:08 PM, mark.reinhold at oracle.com wrote:
>> ...
>> 
>> I'm concerned mostly about the complexity of the language specification,
>> which affects all users of this module system.  If we change the language
>> of module declarations to allow arbitrary module names, possibly via some
>> sort of quoting scheme, then that's something that every developer would
>> have to understand even though it would most likely be of benefit to few.
> 
> You don't need a quoting scheme to allow arbitrary names - you just 
> allow them - and I don't see how this complicates the language 
> specification in any way: in fact it should simplify it.  There's just 
> no reason to use "internal form".

At present the JLS does not allow identifiers to be composed of arbitrary
characters.  If that's what you really want in the source language then
you'd have to introduce some sort of quoting scheme to allow whitespace,
all punctuation characters, and whatever else isn't already allowed by
`Character::isJavaIdentifierPart`.  That would add significant complexity
to the JLS and, more importantly, would be something that every single
Java developer would have to learn.

Perhaps you don't really mean "arbitrary", however, just "something more
than is allowed in a Java qualified identifier".

>> I'm concerned also, though to a lesser degree, about the complexity of
>> the class-file specification (i.e., the JVMS), the long-term evolvability
>> of that specification, and the complexity of code that reads and writes
>> class files, though the latter is second-order since it mostly affects
>> maintainers of IDEs, compilers, and other kinds of tools rather than
>> developers in general.  If there's a compelling reason to lift the usual
>> restrictions on the representation of qualified names in class files, at
>> least in the case of module names, then I'd like to hear it.
> 
> 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.

Who, in practical terms, would benefit from this added complexity?
You've said that JBoss Modules allows arbitrary characters in module
names, but do you or your users actually use such names in practice?
If so, can you show us some examples?

>> ...
>> 
>> 
>> I don't expect Java EE modules to map directly to Java SE modules, nor
>> do any of the Java EE spec leads with whom I've discussed this issue.
>> EE modules and SE modules are completely different kinds of things.
> 
> On March 11 of this year (and other occasions) I specifically asked 
> exactly that, and you said [1] "Of course we have that expectation -- 
> that's why the requirements include an entire section on dynamic 
> configuration".  Did I misunderstand you then or now, or has something 
> changed?

I don't think anything has changed.

I didn't mean for that statement to imply that I thought that every EE
module would map directly to an SE module, though I see how it can be
read that way.  Apologies for the confusion.

- Mark


More information about the jpms-spec-experts mailing list