Alternatives to automatic modules as a concept

[Stephen Colebourne]

On 16 March 2017 at 16:21, David M. Lloyd <david.lloyd at redhat.com> wrote:
>> 3) Remove the concept of automodules entirely
>>
>> Migration would be slower, but safer. Tooling might evolve to add
>> module-info dynamically as part of the build or runtime system, or by
>> editing all the jar files in Maven Central to have an auto-generated
>> module name.
>
> Indeed, it would be relatively easy to introduce a tool that would assemble
> an arbitrary set of JARs into a module graph, using a configuration
> descriptor for only the most advanced cases (pruning the service list,
> specifying reflection capabilities if they are more specific than "open
> all").  Such a tool would be superior to automatic modules in many ways.
>
> This approach has other important advantages: zero magic (particularly if a
> tool can describe what it has done concisely), and choice of implementation.
>
> Even as I was writing this, a colleague of mine sent me a message that he
> has already independently created such a tool.  The URL is:
> https://github.com/moditect/moditect
>
>> Er, I can't think of a viable option 4.
>
>
> 4) Support a mode of operation where the descriptor is external to the
> module content.
>
> Containers are already going to be doing this anyway after all.  This is
> similar, in a way, to option 3 where tooling (or a person, if we can ever
> break away from this idea of requiring bytecode for this purpose) would be
> able to establish the modular environment without modifying the artifacts.
> This is a model that we use today with success.

I think a solution to automodules cannot _require_ a container or a
tool. Option 3, "remove automodules", merely suggests that by removing
them containers or tools _may_ fill _some_ of the gap. But
tooling/containers can't fill the gap for the key part of automodules,
allowing the author of a module-info.java to depend on something that
has not been modularized. Which is why it is borderline as to whether
option 3 "solves" the specific problem in the original mail.

External descriptors allow an application to be stitched together from
jar files, modularized or not (where guessing module names is fine,
because it is the descriptor for an application, not a public
library). However, external descriptors don't solve the problem where
someone is writing a module-info.java file for a public library and
has to guess a module name for a dependency they don't own.

Note that I'm not disagreeing with the idea of an external descriptor,
just that I think it solves a different problem (and should exist
outside JPMS).

Stephen