Draft JPMS Public Review specification

Robert Scholte rfscholte at apache.org
Sun Mar 12 12:40:00 UTC 2017


Hi Mark,

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]

It is the choice of the jigsaw team that every jar used in a modular  
project must be specified as a requirement in the module declaration. For  
me a subset of requirements would already be fine, while slowly increasing  
the number of requirements with every release of the project to make it  
more and more stable. Anyhow, I can live with this decision, but is comes  
at a price.

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.

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.

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.

best,
Robert

[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/

On Tue, 07 Mar 2017 17:50:04 +0100, <mark.reinhold at oracle.com> wrote:

> At this point in time the draft specification appears to achieve the goal
> of this JSR.  We have a small and shrinking number of open issues on the
> list [1], and I expect the resolution of those issues to require at most
> modest adjustments to the final draft.  I therefore intend to submit the
> following draft to the JCP PMO to be posted for Public Review:
>
>     http://cr.openjdk.java.net/~mr/jigsaw/spec/
>
> Please let me know by 17:00 UTC next Tuesday, 14 March if you think any
> changes are required, or if you need more time for review.
>
> - Mark
>
>
> [1] http://openjdk.java.net/projects/jigsaw/spec/issues


More information about the jpms-spec-experts mailing list