The split package problem

[Jochen Theodorou]

On 04.11.2016 15:29, Alan Bateman wrote:
> On 04/11/2016 13:22, Jochen Theodorou wrote:
>
>> :
>>
>> well... assume you have an application and it requires the library A,
>> which transitively requires B-1. the application also requires library
>> C, which transitively requires B-2. B-1 and B-2 are not compatible.
>> library A and D leak instances of classes of B-1 and B-2 to the
>> application.
>
> Assuming B-1 and B-2 export the same packages, A `requires transitive
> B-1` (because a method in A's API returns a B type), C `requires
> transitive B-2` (because a method in C's API returns a B type) then you
> will get an exception when attempting to create the configuration. The
> exception will tell you that the application module reads two modules
> (B-2 and B-2) that export the same package to the application.

I can compile the application if there is only B-1 or B-2 available at 
that time, regardless of if that is actually the wrong version for A or 
C. jigsaw does after all not care about the versions. This would mean 
the application cannot be run with only B-1 or B-2 of course. And it 
means I cannot run the application normally either.

> Attempting to do this with multiple configuration + layers isn't going
> to help, it's just not safe, and you'll get the same exception.

One layer with B-1 and C and another with B-2 and D and my application 
"reading" from those layers... is that something that cannot be done? So 
far I had the impression I can

> You can of course go off-piste and use the reflective API to have the
> application read both B-1 and B-2, and if it its your own class loaders
> then you can go crazy with split delegation, but that is not something
> that you get out of the box.

you rarely get the classloader hell problem out of the box either. And 
configurations like the ones above are not all that rare for me... just 
so far that had been with classloaders only, now it would be with 
classloader and modules and layers

bye Jochen