Draft JPMS Public Review specification
Tim_Ellison at uk.ibm.com
Sun Mar 12 22:54:41 UTC 2017
"jpms-spec-experts" <jpms-spec-experts-bounces at openjdk.java.net> wrote on
> Hi Mark,
> As promised a small set of concrete examples:
> In the JAR File Specification I'm missing the option to add the
> `Module-Name` attribute to the new JAR-file manifest.
> 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.
> me a subset of requirements would already be fine, while slowly
> 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
> 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
> 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, or actually
> 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
> won't work. The resolution for automodules should not be the (only)
> to decline numbers at the end.
I agree that we should drop the proposal addressing
that module names must end with a Java letter. Based on practical
there are a number of libraries that have attempted to use a number
legitimately (i.e. not as a version identifier) and been caught out by
There are any number of bad practices that could be accomplished within
current design, and attempting to spec them out of existence is quite
This proposal introduces friction to adoption for a very limited gain.
> 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
> 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,
> it is intended.
> Based on the Java Platform Module System: Requirements I don't see
> 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.
>  http://cr.openjdk.java.net/~mr/jigsaw/spec/jar.html#Modular
>  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
> > of this JSR. We have a small and shrinking number of open issues on
> > list , and I expect the resolution of those issues to require at
> > modest adjustments to the final draft. I therefore intend to submit
> > 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
> > changes are required, or if you need more time for review.
> > - Mark
> >  http://openjdk.java.net/projects/jigsaw/spec/issues
Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
More information about the jpms-spec-observers