Module descriptions versus module descriptors

[mark.reinhold at oracle.com]

2015/10/20 4:27 -0700, david.lloyd at redhat.com:
> I see no logical path that leads from the requirements as specified 
> exclusively to the assumption that the descriptor must be bytecode, let 
> alone part of the JVM and/or language specification. All the reasons 
> given appear to be self-justifying or based on abstract assumptions, 
> e.g. "modules are... a new kind of Java program component... therefore 
> [Jigsaw] treats them as such".

I agree that there are other ways to represent module descriptions.
I've never stated otherwise.

If module boundaries, however they're expressed, are to be enforced by
the compiler and the VM -- as you've agreed elsewhere -- then their
manner of expression is inevitably going to be a topic for the Java
language and VM specifications.  This is not avoidable.

>           ... it seems to me that a significant part of the Jigsaw 
> design justification for its handling of module metadata hinges around 
> the conflation of the description of a module, and the descriptor used 
> by the static module loading implementation.  This raises a red flag for 
> me because it fundamentally locks the capabilities of module 
> descriptions to whatever makes sense to express in the descriptor, and 
> then in turn constrains these things to the language and JVM specification.
> 
> In our (JBoss) module system, these concepts are decoupled: a filesystem 
> module's descriptor is read and parsed into a description which is then 
> consumed by the module system to create the module.  ...

If module boundaries are to be enforced by the compiler and the VM then,
in such a decoupled system, where and in what form does the compiler
locate the information that describes the module being compiled, and any
other modules required in order to compile that module?

(See also my previous reply on this topic [1].)

- Mark


[1] http://mail.openjdk.java.net/pipermail/jpms-spec-experts/2015-October/000151.html