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-observers
mailing list