Module descriptions versus module descriptors

[Ali Ebrahimi]

Hi,

On Thu, Dec 10, 2015 at 4:56 AM, <mark.reinhold at oracle.com> wrote:

> 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?
>
agreed. language part of spec excludes to java language developers so other
language developers can use whatever format they want, but final food for
jvm would be module-info.class.

I wonder why ceylon had chosen module.ceylon for module descriptions (and
not stayed with module.xml files).

-- 

Best Regards,
Ali Ebrahimi