Proposal: #AutomaticModuleNames
forax at univ-mlv.fr
forax at univ-mlv.fr
Thu Apr 6 08:01:35 UTC 2017
----- 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
More information about the jpms-spec-observers
mailing list