Proposal: #AutomaticModuleNames

[forax at univ-mlv.fr]

----- Mail original -----
> De: "mark reinhold" <mark.reinhold at oracle.com>
> À: "Remi Forax" <forax at univ-mlv.fr>
> Cc: jpms-spec-experts at openjdk.java.net
> Envoyé: Mercredi 5 Avril 2017 01:53:30
> Objet: Re: Proposal: #AutomaticModuleNames

> 2017/4/4 3:33:28 -0700, Remi Forax <forax at univ-mlv.fr>:
>> 2017/4/3 9:30:15 -0700, mark.reinhold at oracle.com:
>>> ...
>>> 
>>> 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.
> 
> I agree with that line of reasoning too, but I think it's essentially
> equivalent to the points I made about standardization and convention.
> 
>>> - 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.
> 
> Glad to hear it.
> 
>>> - 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.
> 
> I'm not convinced.  We want developers just getting started to feel free
> to experiment with automatic modules without shame.  Confronting them
> with warnings right away could be counterproductive.

You maybe right, at the same time, we have just introduced --permit-illegal-access ...

> 
>>>     - 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.
> 
> That's asking people to use a different tool.  The intent of the above
> suggestions is to highlight the presence of automatic modules in their
> full context, at run time, via the launcher itself.

ok, did not get that, i agree, it's better if the warning comes from the launcher itself.

> 
>>> - 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 ?
> 
> An automatic module is just a plain old JAR file, so I don't think we
> can ask them to stop publishing those.
> 
> I do think it'd be a fine thing for all the major artifact repositories
> to refuse to publish explicit modules that require modules that are only
> available in automatic form, i.e., as plain old JAR files.

yes, i was thinking exactly that, Sonatype (and others) should not allow in public repos, artifacts that have automatic modules as dependencies.
I think we should add something like that in the spec as a recommendation.  


> 
>>> - 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.
>>> 
>>> ...
>> 
>> 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.
> 
> There's another quick fix: If you don't like the automatic-module name
> of your library then rename its artifact to have an automatic-module
> name that you do like.  It's fairly straightforward to rename artifacts
> in Maven [b].

yes, but that not the point, the point is to have a stable name.

> 
>> Creating a module-info only works if all your dependencies are modular
>> too, that's why we have automatic module.
>> 
>> ...
>> 
>> 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.
> 
> People really hate warning messages today, as they should.  I can see
> using them for things that are dangerous from the very start, such as
> breaking encapsulation globally.  If, however, we use them for things
> that are acceptable now but become unacceptable in some later release,
> such as the `Module-name` attribute, then we risk teaching people over
> time to ignore all warning messages.  I'd rather not reduce the value
> of warning messages in general just to support this attribute for a
> couple of releases.


ok, so let add Module-Name in the spec, having stable name is really something important,
and as i said, it rewards people that migrate soon to the modular world.

> 
> - Mark
> 
> 
> [b] https://maven.apache.org/guides/mini/guide-relocation.html

Rémi