On 04/11/16 13:22, Jochen Theodorou wrote:
> "classloader hell" goes far beyond the classpath. The problem is rarely
> caused by a classloader that loads two versions of the same library with
> different classes. But happens then more easily if your classloaders
> suddenly have to become forests. Frankly I do not see how modules will
> avoid that.

Yes, indeed, "classloader hell" goes far beyond the classpath. Jigsaw
provides a structured way of dealing with the specific aspect of the
classloader problem Remi mentioned viz detecting and rejecting
resolve-time ambiguities. That doesn't avoid the possibility of runtime
ambiguity i.e. you can still pass an instance of Foo as loaded by layer
A to code which has its own version of Foo as loaded by layer B and get
an error. I don't think I claimed Jigsaw was Dr Quack's Patent Snake Oil
Remedy and Cure-All rather that it would be of some help :-)

> 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.
> 
> 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?

> 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.

regards,


Andrew Dinn
-----------
Senior Principal Software Engineer
Red Hat UK Ltd
Registered in England and Wales under Company Registration No. 03798903
Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander

Reply via email to