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