mark.reinhold at oracle.com
mark.reinhold at oracle.com
Wed Dec 7 23:38:16 UTC 2016
2016/12/5 16:12:06 -0800, david.lloyd at redhat.com:
> On 12/05/2016 05:05 PM, mark.reinhold at oracle.com wrote:
>> 2016/11/29 18:47:33 -0800, david.lloyd at redhat.com:
>>> 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.
> OK I think I see the disconnect here. Here's what I'm reading from what
> you're saying: The JLS says that names have to be one of: a qualified
> names, an identifier, or some new invented thing that would have to be
> added to the JLS, and if it's the last, that's a problem for new
> developers and probably for a few other reasons as well.
Right. Just about the last thing we want is additional complexity in the
> I have no disagreement with this point at all.
> I'm only requesting that
> the backing representation in the JVM/class file spec and/or
> ModuleDescriptor.Builder side have no particular restrictions. Can
> these two concepts be decoupled somehow? I recognize that this means
> that javac-generated descriptors can never reference modules with
> "invalid" (according to the JLS) names, but I don't see that as a
> problem: this is solely for modules which are generated and referenced
> by our container code from some other existing module scheme.
If you can live with that then yes, I think we can make something work.
> The reason I am opposed to using an obfuscation scheme in this case is
> simple: it makes the diagnostic output and calls to get the name of your
> current module have a confusing result, and this mechanism is one of
> only two value propositions of Jigsaw that cannot currently be otherwise
> achieved without special JDK support (the other being the new
> security/encapsulation feature). The .-to-/ mapping of internal names
> is particularly irksome.
Understood. I do think, though, that we should reserve a few characters
for future use. I'll make a specific suggestion in my reply to RÃ©mi in a
moment, since it's also related to an issue he raised about the structure
of class files.
More information about the jpms-spec-observers