On [1] the conclusion given the premise is not unreasonable. The file name can be easily changed by a developer or build tool to match the expected module name. However, it is the premise I strongly object to:
"The fundamental problem here is that we're trying to infer a .. name..." Inferring a name (identifier) is generally a bad idea in any programming context, but especially so in this one where it will be baked into the compiled artifacts. Accepting that inferring a name is a fundamentally bad idea leads to examination of alternatives to automatic modules [3]. Such an examination yields an approach where a module only specifies dependencies on proper modules, with some ability to express that its dependencies are incomplete. This appears not to have been considered despite being equivalent in aiding migration yet avoiding any need to infer a name. As such, on [2], I find the new warnings to be little more than a sticking plaster on the wart of automatic modules. The need to add a disclaimer "Strongly advise developers never to publish, for broad use, explicit modules that require automatic modules" while a welcome recognition of the problem, merely serves to emphasise how broken the concept of automatic modules is. They simply should not be part of the Java platform, a millstone around our necks forevermore. All I hope the teams at Maven, Gradle, Sonatype, JFrog and others can work to ensure strong validation to exclude automatic modules from public repositories, although this is merely an attempt to lock the door after the horse has bolted. I also note that proposals to date do not provide strong guidance on module naming. As things stand, there is likely to be inconsistency in the choices made between projects. This is particularly galling given the extremely strong guidance about NPM and the need for namespaces [4] [5]. It is important to note the impact of what happens when projects collide due to lack of appropriate namespacing [6] [7]. While boring and verbose, reverse DNS is the approach that has served Java well for 20+ years, and should be strongly promoted here. Stephen [1] http://mail.openjdk.java.net/pipermail/jpms-spec-experts/2017-April/000666.html [2] http://mail.openjdk.java.net/pipermail/jpms-spec-experts/2017-April/000667.html [3] http://mail.openjdk.java.net/pipermail/jigsaw-dev/2017-March/011686.html [4] http://mail.openjdk.java.net/pipermail/jpms-spec-experts/2017-January/000537.html [5] https://github.com/npm/npm/issues/798 [6] http://blog.npmjs.org/post/141577284765/kik-left-pad-and-npm [7] https://www.techdirt.com/articles/20160324/17160034007/namespaces-intellectual-property-dependencies-big-giant-mess.shtml On 3 April 2017 at 17:35, <mark.reinh...@oracle.com> wrote: > Thanks for the continued feedback on this difficult issue. > > FYI: > > > http://mail.openjdk.java.net/pipermail/jpms-spec-experts/2017-April/000666.html > > http://mail.openjdk.java.net/pipermail/jpms-spec-experts/2017-April/000667.html > > - Mark