The split package problem

[Andrew Dinn]

On 04/11/16 09:33, Alessio Stalla wrote:
> Also, I think there is a problem related to how class loading works. In the
> vanilla world of Java apps with a single classloader, if you load classes
> in the same (source) package from different sources, the end up in the same
> (runtime) package. But if you have different classloaders at play, and load
> a class p.C1 from classloader 1 and p.C2 from classloader 2, even if they
> share the same (source) package, p, they end up in different (runtime)
> packages, let's call them p(1) and p(2). Therefore, C2 cannot access the
> protected members of C1. That can be confusing.

Modules are not going to stop you having two different runtime versions
of a class. You can do that by loading the same module in two unrelated
module layers. However, what is guaranteed is that those two versions
cannot be conflated thanks to resolution-time ambiguity.

n.b. the above only applies ot code in named modules; classpath
deployment still allows split packages and hence is still susceptible to
resolution-time ambiguity.

regards,


Andrew Dinn
-----------