Module descriptions versus module descriptors
David M. Lloyd
david.lloyd at redhat.com
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).
--
- DML
More information about the jpms-spec-experts
mailing list