Proposal: #AutomaticModuleNames
mark.reinhold at oracle.com
mark.reinhold at oracle.com
Thu Apr 6 15:21:21 UTC 2017
2017/4/6 1:01:35 -0700, Remi Forax <forax at univ-mlv.fr>:
> 2017/4/4 16:53:30 -0700, mark.reinhold at oracle.com:
>> 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:
>>>> ...
>>>>
>>>> - 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.
Agreed -- an automatic module name computed from the name of your
artifact, even if it's a name that you like, is not quite as stable
as the value of a `Module-Name` attribute would be. Still, it is
a way to help prepare your users for the future.
>>> 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.
I completely agree that having stable names is important, but I'm also
firmly convinced that they should be chosen consciously and with due
care by module authors and maintainers -- and no one else.
The trouble with the `Module-Name` attribute is that it makes it too
easy for people other than module authors and maintainers to establish
the stable names of modules. That's inappropriate, and we should not
enable it.
As to encouraging people to migrate to the modular world sooner rather
than later, just adding a `Module-Name` attribute doesn't really count
as migration. Actual migration requires you to write a proper module
declaration, and if the only way to claim a stable name is to do that
then this seems likely to encourage more developers to do so.
- Mark
More information about the jpms-spec-experts
mailing list