On 4 May 2017 at 18:38, <mark.reinh...@oracle.com> wrote: > - Define a JAR-file manifest attribute, `Automatic-Module-Name`, whose > value is used as the name of the automatic module defined by that JAR > file when it is placed on the module path, as previously suggested
This is a step forward wrt automatic modules. > If a JAR file on the module path does not have such a > manifest attribute then its automatic-module name is computed using > the existing filename-based algorithm. Which we all agree is almost guaranteed to be wrong. > - To increase awareness of when automatic modules are used, and of the > consequences of their use, suggest that Java language compilers issue > two new types of warnings, and implement these warnings in the RI: Perhaps these should be reconsidered? If the module depends on an automatic module with a module name in the manifest, it can be considered reasonably stable. Whereas anything depending on a filename derived module name is unstable. That isn't being captured by the warnings. > In related threads on jigsaw-dev both Stephen Colebourne [e] and Robert > Scholte [f] suggest a new kind of explicit module, variously called > "partial" or "incomplete" or "soft", which can read all unnamed modules > so that dependencies that have not yet been modularized can be left on > the class path. This is an attractive notion on the surface, and in fact > one that we partly implemented in the prototype code base over two years > ago, using the term "loose". We didn't pursue it then, however, and I > don't think it's worth pursuing now, for two reasons: > > - If "partial" (or whatever) modules were to replace automatic modules > then application developers would have to wait until all of their > dependencies have been at least "partially" modularized before they > can even begin to experiment with modularizing their own code. This seems demonstrably false. module com.foo.application { requires com.foo.lib; } partial module com.foo.lib { exports com.foo.lib; // TODO: requires guava // TODO: requires joda-beans } modulepath = application classpath = guava, joda-beans The application developer can write the module declarations above, and use them even though all the external dependencies are yet to be modularised. It seems clear to me that the application developer has modularised their application, even if not completely. Given that this seems demonstrably false, I find the claim that "application developers would have to wait" rather odd. This suggests that something is perhaps not fully understood in the text above or the partial proposal. > - We could solve that by keeping automatic modules and adding partial > modules, but then we'd have a more complex module system and a more > complex story to tell. I agree with this. For me it either automatic or partial, not both. And partial is a lot better in technical and community terms IMO as it is a mechanism for reliable gradual migration. I still fail to see why dumping the jars of the classpath on the modulepath and hoping it works is a good strategy for migration - it seems like a bad short cut. Stephen On 4 May 2017 at 18:39, <mark.reinh...@oracle.com> wrote: > Thanks to everyone, and especially Stephen Colebourne, Brian Fox, and > Robert Scholte, for the extensive feedback. > > > http://mail.openjdk.java.net/pipermail/jpms-spec-experts/2017-May/000687.html > > TL;DR: Keep automatic modules, bring back the module-name JAR-file > manifest attribute, and strongly recommend reverse-DNS module names. > > Comments? > > - Mark