The split package problem

[Jochen Theodorou]

On 04.11.2016 15:54, Andrew Dinn wrote:
[...]
>> Problem number 1, how to start this if application, A, D, B-1 and B-2
>> are modules? You don't care that the module system does not allow for
>> this, you have to run it in that configuration and you have to have a
>> way around this. Which means you will have to load modules dynamically
>> in different layers. At this point the benefit already become a burden
>> and is nullified as benefit.
>
> Is this any more of a burden than 1) having to have arrange a tree of
> classloaders to ensure that A sees B1 and D sees B2 and 2) then ensuring
> that instances of B1 and B2 leaked from A and D don't get conflated by
> the app? Would that not by the same token nullify the benefits of having
> a classpath?

the classpath is not there to solve this.

>> Problem number 2... the layers in which B-1 and B-2 reside in still have
>> their own versions of classes, which are by name equal in B-1 and B-2.
>> If application is actually using classes directly from B-1 or B-2 you
>> get the classloader hell problem, just the same as you would without the
>> module system beyond considering the classpath.
>
> Yes, fixing resolve-time ambiguity doesn't fix runtime ambiguity. So, if
> your problem is runtime ambiguity then you'll still have to fix that.
> But not being able to fix one mess doesn't mean Jigsaw is of no help for
> another mess.

for the other mess I usually use gradle

bye Jochen