Proposal: #AutomaticModuleNames

Tue Apr 4 12:43:42 UTC 2017

The Module-Name was enough of a hook to allow us to have Maven "fix" this
problem automatically by inserting a name based on the coordinates. Taking
that away I think again ties our hands.

On Tue, Apr 4, 2017 at 11:33 AM, Remi Forax <forax at univ-mlv.fr> wrote:

> 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/#Automat
> icModuleNames
> > [2]
> > http://mail.openjdk.java.net/pipermail/jpms-spec-experts/201
> 7-January/000537.html
> > [3]
> > http://mail.openjdk.java.net/pipermail/jpms-spec-experts/201
> 7-April/000666.html
> > [4]
> > http://mail.openjdk.java.net/pipermail/jpms-spec-experts/201
> 7-February/000582.html
> > [5] http://openjdk.java.net/projects/jigsaw/spec/issues/#ModuleN
> ameInManifest
> > [6]
> > http://mail-archives.apache.org/mod_mbox/maven-dev/201702.mb
> ox/%3CCAMk_Beg2ir9e65hXG9RSNVFdWNYMr02aTh%3Dd%3DfCWL%2BWof-
> aXpw%40mail.gmail.com%3E
>