The split package problem

[Jochen Theodorou]

On 04.11.2016 11:50, Andrew Dinn wrote:
[...]
>  - Modules stop you providing two versions of a package in the same
> layer, a problem for classpath deployment which, as Remi noted, can
> easily lead to you mixing classes from two different versions of a library.

but sometimes you have to do something similar to that. Usually you then 
start with classloader magic and have to find your way around 
"duplicated classes".

What is targeted with modules is that this is done by accident. And 
frankly, my experience was that those accidental cases have been 
resolved pretty fast.

>  - You can indeed use a dynamic module loading system based on layers to
> introduce versions of the same classes in different layers. However, the
> unique package ownership requirements means that those layers cannot
> partake in an ancestor relationship again with the result that duplicate
> classes cannot then be conflated in the way Remi described.

sure, nobody really needs that on the classpath... except for a poor 
mans patching.

> So, it seems from the above that layers are indeed a structured way to
> avoid one of the major causes of 'classloader hell' precisely because
> they detect and reject deployments which introduce these ambiguities in
> resolution.

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

> Are you suggesting that modules will not provide this specific benefit
> or that some other problem will render it of no importance? If the
> former can you explain why? If the latter can you explain what that
> other problem is?

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.

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.

bye Jochen