Proposal: #ModuleNameCharacters

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


2016/11/29 18:50:11 -0800, david.lloyd at redhat.com:
> On 11/29/2016 06:11 PM, mark.reinhold at oracle.com wrote:
>> ...
>> 
>> As I wrote in my reply to David, I'm open to lifting the traditional
>> restrictions on the class-file representation of qualified names in the
>> case of module names.  Given the weight of tradition and the past value
>> of the existing constraints, however, I'd like to have a more compelling
>> reason than "some future hypothetical module system might need this
>> flexibility".
> 
> The key point is exactly that a present, concrete module system does 
> need this flexibility; ours, specifically.  And this is such an easy change.

No, it's not, as I've tried to explain nearby.

>> In trying to think about the future I do wonder if, today, we should
>> reserve a character or two just in case we discover five or ten years
>> from now that we need to add more structure to module names.  Should
>> we set aside `:`, or perhaps some other character, just in case?
> 
> We have had a module system with no character restrictions for many 
> years now and never looked back.  It adds flexibility as every module 
> loader can establish acceptable name rules based on its policy, which 
> afforded us a great deal of interoperability with all manner of system. 
> You can still have reserved characters if that's what is appropriate to 
> your module resolver; if a name is invalid for that resolver, the 
> resolver can simply return no match.

I'm puzzled.  The "Module names" page [1] in the documentation of JBoss
Modules says:

  A module name is a dot-separated string which is used along with a
  version slot identifier to uniquely identify a module within a module
  loader.  Names are typically organized along the same lines as package
  names, however there is no specific relationship between a module name
  and the packages it contains.  These are all examples of typical module
  names:

      org.apache.commons.logging
      org.jboss.remoting
      cglib
      javax.ejb.api
      ch.qos.cal10n

  ...

  Version slot identifiers are used when you wish to have more than one
  instance of a module in a module loader under the same name.  ...

  When identifying a module in a string, the version slot identifier can
  be appended to the module name, separated by a colon ":".  For example,
  the following two module identifier strings refer to the same module:

      org.jboss.remoting:main
      org.jboss.remoting

  The following three module identifier strings refer to different
  modules:

      org.jboss.remoting:2
      org.jboss.remoting:3
      org.jboss.remoting

A related page, on "Module descriptors" [2], describes the algorithm for
locating `module.xml` files:

  ... its location on the filesystem is calculated by converting the
  dot-separated segments of the module name to path elements, followed by
  a path element which consists of the version slot for that module. This
  path is then appended to each module path root in turn until a file
  named module.xml is found within it.

Unless I'm misunderstanding something, or the documentation is incorrect
or incomplete, then module names in JBoss Modules cannot be arbitrary
strings.  They cannot contain colons, since colons are used to separate
module names from version-slot identifiers, nor can they contain repeated
dots or slashes, since dots are transformed into slashes and repeated
slashes are, in most filesystems, equivalent to a single slash.  (They
probably also can't contain characters that are illegal in the underlying
filesystem unless some sort of escaping is done, but the documentation
does not address this.)

More to the point, every single module name in the examples in the JBoss
Modules documentation would be considered a qualified identifier in Java.
When and in what circumstances are truly arbitrary module names used in
JBoss Modules?  Or is this simply a theoretical concern on your part?

- Mark


[1] https://docs.jboss.org/author/display/MODULES/Module+names
[2] https://docs.jboss.org/author/display/MODULES/Module+descriptors


More information about the jpms-spec-observers mailing list