Proposal: #ModuleNameCharacters

[Stephane Epardaud]

If you do, you'll have to find a way to encode the imported module names 
in `module-info.java`, though, so that you can import modules produced 
by other module systems/languages. What we have in Ceylon is that you 
can import foo.bar (Ceylon) modules as identifiers, or "foo-bar:gee" 
(Maven) modules as quoted strings.

On 23/11/16 20:59, Remi Forax wrote:
> 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.
> 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.
>
> regards,
> Rémi
>
> ----- Mail original -----
>> De: "David M. Lloyd" <david.lloyd at redhat.com>
>> À: jpms-spec-experts at openjdk.java.net
>> Envoyé: Mardi 22 Novembre 2016 22:05:13
>> Objet: Re: Proposal: #ModuleNameCharacters
>> On 11/22/2016 10:49 AM, mark.reinhold at oracle.com wrote:
>>> Proposal
>>> --------
>>>
>>> Make no changes here.
>> TL;DR: we can't accept this proposal as-is.  Expounding more below.
>>
>>> Modules are a new construct of the Java programming language in the
>>> present design.  In the source language they are hence identified by
>>> qualified names [2] in the same manner as the existing structural
>>> constructs, i.e., packages and classes.  As such these names do allow
>>> some unusual characters, though not hyphens or slashes [3].
>>>
>>> Module names in compiled module-declaration class files are recorded in
>>> `CONSTANT_Utf8_info` structures, and thus have fewer constraints.
>> I believe that according to the JVM spec (until now anyway), this field
>> type by itself has no constraints at all, beyond being a valid
>> "modified" UTF-8 string.
>>
>>> They replace periods (`'.'`) with forward slashes (`'/'`), and disallow
>>> periods, semicolons (`';'`), and left square brackets (`'['`) [4].
>> These name manglings are really just plain weird in this context, and
>> are clearly an implementation artifact.  How did we arrive at this
>> place?  I feel like it springs from the long-maligned conflation of
>> module descriptors with class files.  But modules are not types and
>> AFAICT these restrictions really make no sense from any other
>> perspective than one of implementation.
>>
>>> The `ModuleDescriptor` API can read class files that contain module names not
>>> expressible in the source language, though it cannot be used to construct
>>> instances with such names.
>> This restriction seems arbitrary, but we can mitigate it I guess.
>>
>>>   Artifacts that define modules with such names
>>> will be processed normally when placed on the module path.
>> OK.  Just to be clear though, the use cases that we are dealing with
>> would not involve a module path.
>>
>>> The present design is, then, consistent with the existing treatment of
>>> qualified names in the language, in class files, and in the Java SE API.
>> I do not believe that any of these statements is sufficient to justify
>> the constraint... more below.
>>
>>> A different module system with a more-flexible naming scheme can easily
>>> refer to JPMS modules, per the agreed interoperation requirement [5].
>>> The requirements do not mandate bidirectional interoperation, which for
>>> this issue would mean that JPMS modules must be able to refer to non-JPMS
>>> modules with non-JPMS names.
>> This is also not sufficient to justify the constraint, though it does
>> help to explain the reasoning why the constraint existed in the first place.
>>
>>> To support that would add significant
>>> complexity to this specification and its implementations.
>> I am sympathetic to this, but I think it needs more discussion,
>> particularly as the proposed complexities have not been explained.
>>
>> The overarching problem here for us is that the JPMS specifies a new
>> deployment model which is being put forth as a standard for future
>> development.  However we can't accept a solution which will render
>> existing, otherwise satisfactory, alternative modular deployment models
>> unusable with this new model: for example OSGi, Java EE, or JBoss
>> Modules and its usages in various contexts.  To do so would be, at a
>> minimum, a huge disservice to our users, and would require a large
>> investment to migrate to the new model: a lossy move, because in this
>> case we'd be losing features by definition.
>>
>> Thus one implicit requirement that we have is that we can successfully
>> evolve our deployment models into the JPMS and interoperate fully; else
>> we must choose between sentencing our own deployment models to death or
>> dismemberment, or else being unable to take advantage of the JPMS
>> capabilities (and in either case we would have no motivation to support
>> it, though for different reasons in each case).  While we can
>> theoretically support some name constraints on our model (leaving Java
>> EE aside), the constraints we could support do not match the ones that
>> exist, and therefore this information doesn't really help much.
>>
>> But the other implicit requirement that we have is to ensure that it's
>> possible to adapt Java EE in some reasonable manner.  It's my belief
>> that in order to do so we need to be able to create modules with names
>> that match the current constraints for Java EE module names (i.e.
>> effectively no constraint, just valid UTF-8).  Name mangling to
>> accommodate this (which would be our only other option) is unnecessarily
>> user-unfriendly at best, and outright incompatible at worst.
>>
>> I think we should talk about the factors that are complicating this
>> issue and proceed from there... maybe there's something we can do to help.
>>
>> --
>> - DML