Proposal: #AutomaticModuleNames

Tue Apr 4 10:33:28 UTC 2017

Hi Mark, hi all,
it seems it will be hard to have a consensus on this issue, but i think we can try to find a common ground,

----- Mail original -----
> De: "mark reinhold" <mark.reinhold at oracle.com>
> À: jpms-spec-experts at openjdk.java.net
> Envoyé: Lundi 3 Avril 2017 18:30:15
> Objet: Proposal: #AutomaticModuleNames

> Issue summary
> -------------
> 
>  #AutomaticModuleNames -- Revise the algorithm that computes the names
>  of automatic modules to include the Maven group identifier, when
>  available in a JAR file's `pom.properties` file, so that module names
>  are less likely to collide, or else drop the automatic-modules feature
>  entirely, since it may be more trouble than it's worth.  [1]
> 
> Proposal
> --------
> 
>  - Do not revise the algorithm that computes the names of automatic
>    modules.  The suggestion to use Maven coordinates when available [2]
>    would help less than half of the most popular projects in use today,
>    as determined by three different surveys.  It would result in module
>    names that are either annoyingly verbose or not so obviously related
>    to their artifacts' original coordinates, and in either case known to
>    be objectionable to some module authors.  It would, finally, raise
>    non-trivial issues with regard to standardization and convention.
>    No algorithm better than the current one has been proposed.  [3]

I agree with the conclusion but not the text above.
We should not read any property file generated by Maven just because Maven sit on top of the JDK and not the opposite,
the dependency (in general meaning) goes in the wrong direction. 

> 
>  - Do not drop the automatic-modules feature.  It's a critical part of
>    the overall JPMS migration story, and it's been well-received by a
>    wide variety of developers despite the fact that some expert users
>    are not comfortable with it.

i fully agree.

> 
>  - To increase awareness of when automatic modules are used, and of the
>    consequences of their use, encourage Java language compilers to issue
>    two new types of warnings, and implement these warnings in the RI:
> 
>      - An opt-in (i.e., off-by-default) warning on a reference to
>        an automatic module in a `requires` directive in a module
>        declaration, and

it should be an opt-out one, automatic module are cool in short term and evil in long term, so you need a remainder.

> 
>      - An opt-out (i.e., on-by-default) warning on a reference to
>        an automatic module in a `requires transitive` directive in
>        a module declaration.
> 
>    The first warning allows developers to be maximally hygienic if they
>    so choose.  The second helps make the author of an explicit module
>    aware that they're putting the users of that module at risk by
>    establishing implied readability to an automatic module.
> 
>  - Encourage Java run-time systems to make it easy to identify via,
>    e.g., command-line options, which observable modules are automatic,
>    which observable modules would establish implied readability to
>    automatic modules if resolved, and which automatic observable modules
>    are actually resolved.  Implement these capabilities in the RI.

yes, one simple way to do that is to considere all automatic modules as deprecated (forRemoval=false),
so the tool already exist, it's jdeprscan. 

> 
>  - Strongly advise developers never to publish, for broad use, explicit
>    modules that require automatic modules.  That's risky: An automatic
>    module is unreliable, since it can depend on types on the class path,
>    and its name and exported packages could change if and when it's
>    converted into an explicit module.  It's fine to declare and use
>    explicit modules that require automatic modules in limited settings,
>    but they should never be published to Maven Central or any similar
>    public repository.

yes,
you can formally ask Sonatype to never allow to publish an automatic module ?

> 
>  - Do not implement the previous suggestion to define a `Module-Name`
>    manifest attribute [4][5].  It would be confusing, because it would
>    establish two ways to name a module, one of which is rooted in the
>    past.  It would also make it easy for people other than the author
>    of a module, e.g., tool maintainers [6], to try to establish the
>    module's name via the default effect, a move to which many module
>    authors would understandably object.
> 
>    Not defining this attribute does mean that authors and maintainers
>    who want to modularize existing components yet continue to support
>    those components on earlier releases will have to do a bit more work
>    in order to create `module-info.class` files.  It's straightforward
>    to create standalone tools to address this need for those who are
>    unable or unwilling to build on JDK 9.

Yes, the idea of using the "Module-Name" manifest attribute is an idea of the past,
but it's a quick fix that library author can use to reserve the name of their module before anyone choose a name.

Creating a module-info only works if all your dependencies are modular too, that's why we have automatic module.

While migrating should be done as fast as possible, this will not be done in one night, so i think we still need the "Module-Name" attribute to not punish people that want to run their application on Java 9, because otherwise they will have to change their application again each time one dependency becomes modular.

Perhaps a middle ground is to allow 'Module-Name' in 9 and emit a warning like --permit-illegal-access if an automatic module with a "Module-Name" is used in 10.

Rémi

> 
> 
> [1] http://openjdk.java.net/projects/jigsaw/spec/issues/#AutomaticModuleNames
> [2]
> http://mail.openjdk.java.net/pipermail/jpms-spec-experts/2017-January/000537.html
> [3]
> http://mail.openjdk.java.net/pipermail/jpms-spec-experts/2017-April/000666.html
> [4]
> http://mail.openjdk.java.net/pipermail/jpms-spec-experts/2017-February/000582.html
> [5] http://openjdk.java.net/projects/jigsaw/spec/issues/#ModuleNameInManifest
> [6]
> http://mail-archives.apache.org/mod_mbox/maven-dev/201702.mbox/%3CCAMk_Beg2ir9e65hXG9RSNVFdWNYMr02aTh%3Dd%3DfCWL%2BWof-aXpw%40mail.gmail.com%3E