excluding transitive module

[Alex Buckley]

On 4/15/2020 12:00 AM, Jochen Theodorou wrote:
> On 14.04.20 19:38, Alex Buckley wrote:
> [...]
>> It's fine for
>> Library1 to require SharedApi, and for Library2 to require
>> SharedApiImpl, but if the exported packages overlap, then it's not fine
>> for Project to require, indirectly, both SharedApi (via Library1) and
>> SharedApiImpl (via Library2). That is, SharedApi and SharedApiImpl are
>> not composable.
> 
> And what do you do when you are in that situation?
> 
>> If you had put them both on the classpath in JDK 8, then
>> you would have had a broken system. If you want to compose an
>> application that includes both, then one of them has to change.
>> There is no need to speak of "transitive" modules because `requires
>> transitive` has not entered the picture.
> 
> Without the module system I can just exclude one and be fine. With
> module system I get into a split package problem adn have not found a
> real solution yet

In the JDK 8 world:  If SharedApi and SharedApiImpl have different 
names, then (as you implied to Remi) Maven is going to treat them 
independently and put both on the classpath. Yes, you can realize that 
their content overlaps and exclude one of them in your POM, but *every* 
*single* *user* has to travel that road independently! If a user doesn't 
realize, and doesn't exclude, then their classpath has split packages 
and their application is broken. I think it's outrageous that the 
developers of SharedApi and SharedApiImpl imposed this tax on *every* 
*single* *user* and no-one held them to account.

Post JDK 8:  Only when SharedApi and SharedApiImpl are modularized does 
the presence of overlapping exports become clear, and prevent an 
application from being composed unsafely.

There is nothing you can do in the module-info.java of your application 
to express that its module graph indirectly requires the uncomposable 
modules M,N,O and that any `requires M` and `requires N` clauses should 
be overridden with `requires O`. This would be a maintenance nightmare. 
Mail their developers and tell them what they've done. Every library 
including its own copy of a standard API is a bug, not a feature.

(If a library is explicitly written to be loaded in its own class 
loader, such as in the OSGi environment, then things are different: 
private copies of APIs are OK, up to a point. However, the libraries you 
are using are plainly from the JDK 8 classpath era and have been lightly 
modularized -- enough for each vendor to let their module be required 
and jlinked, but not enough to address the bigger architectural issue of 
reuse / composability.)

Alex