Proposal: #ModuleNameCharacters

[David M. Lloyd]

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