Revised proposal for #AutomaticModuleNames

[Stephen Colebourne]

On 5 May 2017 at 01:19,  <mark.reinhold at oracle.com> wrote:
>> The application developer can write the module declarations above, and
>> use them even though all the external dependencies are yet to be
>> modularised. It seems clear to me that the application developer has
>> modularised their application, even if not completely.
>
> By "modularizing" in the above point I meant "completely modularizing",

Personally, I can't see how a module that depends on an automatic
module can be described as "completely modularized" - it is built on
sand, because the requires names are wrong (filenames).

Having reflected on this overnight, I've come to the conclusion that
the revised proposal still doesn't solve the basic community-level
problem that is blocking adoption.

Consider Joda-Convert that depends on Guava (optionally). With the
revised proposal, I still can't release Joda-Convert until Guava has
been made module aware (either by adding a full module declaration, or
the MANIFEST attribute). The stack of dependencies is still forced to
be upgraded from the bottom-up, which we agree won't work.

If I write and release:

module org.joda.convert {
  requires guava;
}

it will work today with guava as an automatic module. But when guava
upgrades and becomes a complete module, it will stop working (because
the module name will be different). Every project that depends on
Joda-Convert that wants to upgrade Guava cannot do so until
Joda-Convert does another release:

module org.joda.convert {
  requires com.google.common;
}

As an approach, it causes every open source project to become tightly
coupled, something that isn't feasible and which the community would
have to reject. As such, I would not release Joda-Convert as a module
until Guava is done. We'd be back to bottom-up migration. ie. all the
manifest entry does is make the bottom-up migration a little quicker.

Sadly, my view remains that the revised proposal is still broken when
viewed through the open source community lens.


My preference going forward remains partial modules, because they fit
with the development workflow of many/most open source projects (and
probably most closed source ones too). They get developed, with new
features and bug fixes. And from time-to-time, dependencies get
updated. When the dependency is updated, it would be a small extra
step to add the missing "requires" line. I don't buy the need for
"immediate experimentation" - quick things are usually short cuts that
cause more harm than good.

Since it appears unlikely partial modules will be considered, I'll
send a separate thread with another attempt to mitigate the worst
effects of automatic modules.

Stephen