Alternatives to automatic modules as a concept

David M. Lloyd david.lloyd at redhat.com
Fri Mar 17 13:30:35 UTC 2017


On 03/17/2017 03:50 AM, Stephen Colebourne wrote:
> 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).

Something to remember is that naming is ultimately the responsibility of 
the distributor of the final module assembly.  The framework author(s) 
can make a good guess about a name but (particularly where split API and 
implementations or specifications are concerned) there's a very good 
chance that any distributor of a nontrivial application is going to have 
to perform substitutions anyway.  Since this is likely to be a common 
occurrence (at least with larger applications), it should be planned 
for.  If users are already expecting to use tooling to create their 
assemblies, then automodules don't actually help because they just add 
another axis of unpredictability to the assembly process.

I expect an assembly workflow to involve fetching artifacts with preset 
versions, either transforming an existing descriptor or establishing a 
new one (probably based at least on the combination of existing module 
descriptors, Maven metadata, and (possibly) some small amount of user 
configuration, which BTW will result in a far better "guess" than 
automodules possibly could), and then finally bundling up the result in 
some way (either jlink or via a more traditional mechanism).

This is why I think automodules should be dropped: I cannot envision a 
real-world non-trivial development scenario where it could possibly be 
helpful.  And some auxiliary food for thought: today, it will fail on 
any JAR set that includes SLF4J.  Sorry SLF4J fans!

-- 
- DML


More information about the jigsaw-dev mailing list