Alternatives for naming automatic modules, and a proposal (#AutomaticModuleNames)

[Stephen Colebourne]

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.reinhold at 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