Alternatives for naming automatic modules, and a proposal (#AutomaticModuleNames)

[David M. Lloyd]

On 04/26/2017 11:27 AM, mark.reinhold at oracle.com wrote:
> 2017/4/25 5:08:21 -0700, Stephen Colebourne <scolebourne at joda.org>:
>> On 24 April 2017 at 19:54,  <mark.reinhold at oracle.com> wrote:
>>> An explicit module that depends upon one or more modules that are
>>> automatic today is, itself, no more stable than those automatic modules.
>>> It could be broken when those automatic modules are modularized
>>> explicitly, and if it `requires transitive` an automatic module then any
>>> modules that depend upon it could be broken when that automatic module
>>> is modularized explicitly.
>>
>> I find this to be a completely artificial pure view of the world. Most
>> projects do not have internal packages, and if they do, most end-users
>> do not use them. When developers upgrade an artifact in Maven, they
>> expect to have incompatibilities, so a smaller set of packages is just
>> fine. Its a normal part of software development today, not an
>> aberration.
>
> If developers expect to have to fix incompatibilities when they upgrade
> to a newer version of an artifact then what's wrong, after all, with
> publishing an explicit module that depends upon non-modularized
> components in the form of automatic modules?
>
> If one of those automatic modules is modularized later on, and given a
> different name, then how is having to fix that materially different from
> having to fix code that was using a package that's no longer exported?

I'd say the primary difference is that it is almost guaranteed that the 
artifact will have a new name, whereas it's far, far less likely that 
code will be using packages that are not then exported when the 
automatic module is modularized.  The chain of logic where it's OK to 
introduce minor problems because people are used to fixing minor 
problems doesn't hold up.  Minor problems are minor in large part 
because they don't occur frequently.

> If anything it might actually be easier to cope with a module-name
> change, since all you have to do is edit a `requires` directive; code
> that refers to a package that's now encapsulated might require a
> non-trivial rewrite.
>
> I think I need to reconsider my previous conclusion that explicit modules
> that depend upon automatic modules should never be published for broad
> use [2].  Sure, they have unstable names and unstable APIs but if, as you
> say, people are generally used to fixing minor problems when they upgrade
> then this instability may well be tolerable -- especially since it would
> allow maintainers to modularize whenever they want to rather than only
> after all of their dependencies have been modularized.

Essentially it means that a fully modularized module *must* publish a 
new version every time an automatic dependency is properly modularized. 
This is an unreasonable extra burden to place on developers.

But, I don't believe that any of the pitfalls of automatic modules will 
really matter in practice, particularly as better migration tooling 
(than automatic modules) emerges.

-- 
- DML