Proposal: #AutomaticModuleNames

mark.reinhold at oracle.com mark.reinhold at oracle.com
Tue Apr 4 23:53:30 UTC 2017


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.

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

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

>> - 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].

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

- Mark


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


More information about the jpms-spec-experts mailing list