David M. Lloyd
david.lloyd at redhat.com
Tue Dec 6 00:12:08 UTC 2016
On 12/05/2016 05:06 PM, mark.reinhold at oracle.com wrote:
> 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
>> 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  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
Yes, this documentation covers defining modules statically for the
consumption of the filesystem module loader. Internally though, there
is no restriction for modules which are generated on the basis of other
module systems or class loading schemes. This situation is highly
analogous to what I've requested in my other email.
> 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.)
Right, see above and my other email on this topic to understand why this is.
> 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?
Yes, our static filesystem modules should be well covered already.
More information about the jpms-spec-observers