Module descriptions versus module descriptors

David M. Lloyd david.lloyd at
Tue Oct 20 23:27:51 UTC 2015

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 propose instead that this and every other aspect of the JSR 
implementation be as *decoupled* from the JVM and Java specifications as 
possible, only coupling them when that is the only way to achieve a 
requirement.  Once you get rid of the assumption that modules and their 
descriptors ought to be a part of the language as a first principle, it 
becomes obvious to me that there is really no other specific reason or 
use case for them to be.

Additionally, 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.  This enables us to 
provide additional capabilities - like class transformation, customized 
filtering, customized dependency ordering rules, customized resource 
roots, etc. - which do not make sense for the simple static modules used 
to bootstrap the system.  This also allows us to support multiple module 
descriptor methodologies or formats, including descriptions derived from 
Java EE or OSGi metadata (or even Maven metadata), and gives us 
flexibility to completely customize module wiring within our containers 
without compromising the contract of the module system in any way 
because simple descriptors are no longer "special" citizens; they 
consume the same API as everyone else (meaning users have the exact same 
capabilities as the system).


More information about the jpms-spec-experts mailing list