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
