Initial module-system design, API, and prototype
David M. Lloyd
david.lloyd at redhat.com
Wed Sep 9 20:48:12 UTC 2015
On 09/09/2015 11:51 AM, mark.reinhold at oracle.com wrote:
> To get the discussion started I suggest we focus first on the high-level
> aspects of the design covered in "The State of the Module System" .
>  http://openjdk.java.net/projects/jigsaw/spec/sotms/
1) The first thing that jumps out at me (again) is making module
declarations be a binary construct produced by the actual programming
language. It strikes me as arbitrary as well as redundant (given
there's a programmatic API to build descriptors, they could simply be
parsed from text nearly as well, and a lot more nicely from the user's
perspective). As pointed out in the document, it is already expected
that additional tooling would synthesize this file at build time,
further decreasing the value of such an idea. The module class file
just seems pointless to me.
2) The integration of the descriptor into user module artifacts is also
concerning for a variety of additional reasons:
* Dependency information is non-absolute, and in fact depends very much
on the environment and on conditions which can and do change over time.
* Any mistake in the description potentially renders the artifact
useless, since changing the artifact contents would invalidate any
digital signature or hash.
* Even versioning is really the conflux of the original source code, the
compilation environment, and the module distribution environment; for
reference, note how OS distributions nearly always ship customized
versions of all nontrivial content.
These factors, I think, would unfortunately preclude public code
repositories which distribute modules in this format. Such repositories
would have to instead ship a bootstrap module which could in turn
establish module dependencies in a different way, to ensure that the
description information can be handled separately from the code
artifacts themselves, fracturing the nascent ecosystem before it can
even establish itself. It's not clear how such an ecosystem is expected
to function otherwise.
3) Readability and other terminology
"Readability" is the term that we were calling "visibility" up until
this point, correct? And the term "implied readability" is what I would
have erstwhile called a transitive dependency.
Also, "exports" in this document appear to apply only to package names
and not module dependency names.
I am concerned that layers do not go far enough to ensure that different
module graphs can interoperate. There is seemingly no provision to
establish dependency relationships between modules in different layers,
because layers are apparently strictly hierarchical. This would make it
much more difficult to (for example) allow different containers to
interoperate within an app server (OSGi and Java EE, for example).
Today we use this kind of relatability to allow Java EE modules to
depend on modules constructed out of the legacy extensions system as
well as filesystem-backed JARs which are modularized independently of
our Java EE container, allowing them to be reused from other containers
More information about the jpms-spec-observers