Draft JPMS Public Review specification

[mark.reinhold at oracle.com]

2017/3/12 5:40:00 -0700, rfscholte at apache.org:
> As promised a small set of concrete examples:
> 
> In the JAR File Specification[1] I'm missing the option to add the  
> `Module-Name` attribute to the new JAR-file manifest.[2]

I haven't yet added that attribute to the JAR-file specification because
#ModuleNameInManifest is tightly related to #AutomaticModuleNames [5],
and while we've made progress on that issue I'm not yet sure that we've
found the best solution.  I'll have more to say on that topic shortly, but
either way I suspect that whatever we conclude will result in most minor
changes, so this issue needn't hold up the Public Review submission.

> ...
> 
> Maven won't allow references to automodules in case of libraries for  
> reasons discussed in other threads.
> Our definition of a library is that is has at least 1 export-statement.  
> 
> Referring to named modules, either by the name in the module-info file or  
> the `Module-Name` attribute, is fine.
> For applications (without any export-statement) referring to automodules  
> can be done with minimal danger.
> 
> For ease of transition, the `Module-Name` is simply a requirement,  
> otherwise libraries can only start adding the module declaration once  
> every required module is named. Until that moment this project could not  
> claim a module name, nor can it be referred to by other libraries.

Okay, I understand this to mean that you strongly want the `Module-Name`
attribute.  Noted for future discussion.

> I have the feeling that VersionsInModuleNames[3], or actually modulenames
> ending with numbers should be allowed. In case of automodules, there are
> cases where this would help, but also a same amount of modules where this
> won't work. The resolution for automodules should not be the (only) reason
> to decline numbers at the end.

I understand the objections to this constraint, but I think it's
essential to provide some sort of mechanical advice to developers to
guide them away from encoding version numbers in module names.  Perhaps
there's some other way to do that?  If not, then aside from `fabric8`
and `commons-lang3` would this constraint actually impact any other
well-known projects?  (Perhaps a scan of Central could guide us here.)

> David suggested to reopen #CyclicDependences and based on his story I  
> agree that this one should be reconsidered. The problem can arise at  
> runtime when a combination of versions of different modules come together  
> and create a cycle, whereas at compile time (with a different set of  
> modules) everything looks fine. I don't think that it is the  
> responsibility of the JVM to prevent cycles, there are other tools which  
> can detect cycles and warn about it and where you can suppress it, because  
> it is intended.
> 
> Based on the Java Platform Module System: Requirements[4] I don't see any  
> goal specification regarding cyclic dependencies. It looks more like a  
> bonus you achieved with the JDK/JRE itself to make it possible to link  
> small assemblies, but the outer world sometimes needs this trick.

It's true that the agreed requirements don't say anything about whether
or not cycles should be allowed.  Disallowing them does, however, bring a
number of significant advantages, as noted in the issue statement [6].
The designers of some other module systems have found it useful to allow
cycles, but JPMS differs from those in a couple of essential ways that
bear upon this issue:

  - JPMS is not highly dynamic, so if a cycle arises while configuring
    a layer then that fact will be reported early, when it's easier to
    diagnose, rather than at some (possibly much) later point in time.

  - JPMS aims to provide a clear migration path for existing components,
    but it assumes that components can and will be revised during that
    process.  If a cyclic module graph arises then the maintainers of
    the relevant components should consider whether a service should
    be introduced in order to break the cycle.

Taken together with the compelling arguments against cyclic module
relationships made by at least one noted expert in the field [7], on
balance I think it's best to disallow cycles in JPMS for now.  If actual
experience with JPMS as used directly by developers -- rather than as
an embedding target for other module systems -- suggests that we should
allow cycles then we could enable them in a future release.  If we enable
them now, however, then we can never take them back.

- Mark


> [1] http://cr.openjdk.java.net/~mr/jigsaw/spec/jar.html#Modular
> [2] http://openjdk.java.net/projects/jigsaw/spec/issues/#ModuleNameInManifest
> [3] http://openjdk.java.net/projects/jigsaw/spec/issues/#VersionsInModuleNames
> [4] http://openjdk.java.net/projects/jigsaw/spec/reqs/

[5] http://openjdk.java.net/projects/jigsaw/spec/issues/#AutomaticModuleNames
[6] http://openjdk.java.net/projects/jigsaw/spec/issues/#CyclicDependences
[7] http://www.kirkk.com/modularity/2009/12/acyclic-relationships/