Draft JPMS Public Review specification

[Tim Ellison]

"jpms-spec-experts" <jpms-spec-experts-bounces at openjdk.java.net> wrote on 
12/03/2017 12:40:00:
> 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.

I agree that we should drop the proposal addressing 
#VersionsInModuleNames,
that module names must end with a Java letter.  Based on practical 
experience
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 
this.

There are any number of bad practices that could be accomplished within 
the
current design, and attempting to spec them out of existence is quite 
futile.
This proposal introduces friction to adoption for a very limited gain.

Regards,
Tim

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

Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 
741598. 
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU