Initial module-system design, API, and prototype

[David M. Lloyd]

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" [1].
>
> [1] 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.

4) Layers

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 
as well.

-- 
- DML