Module descriptions versus module descriptors

Remi Forax forax at
Wed Oct 21 08:48:24 UTC 2015

I may say something stupid because i'm not sure to have fully understood your mail.

For me, a module descriptor is defined by the interface java.lang.module.ModuleDescriptor.
I think you can create a ModuleDescriptor from any representation using the builder (ModuleDescriptor.Builder).
So at runtime, a module descriptor is just anything that implements that interface.

At compile time, it's different because you may want a textual representation for the compiler,
at least one by default, the compiler API maybe be pluggable enough to provide your own ModuleDescriptor*,
this textual representation is the file, because as Mark said, the compiler consumes Java source files.

With that, a module descriptor can be hand written by a developer or generated by a build tool,
exactly like it's not required to have a java source file to create a java class at runtime.


* This is not as easy as it sound because you need a class of Java 9 when you bootstrap your compiler to create the compiler of Java 9. 

----- Mail original -----
> De: "David M. Lloyd" <david.lloyd at>
> À: jpms-spec-experts at
> Envoyé: Mercredi 21 Octobre 2015 01:27:51
> Objet: Module descriptions versus module descriptors
> 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).
> --
> - DML

More information about the jpms-spec-experts mailing list