[jsr294-modularity-eg] Superpackage defining class loader

[Andreas Sterbenz]

Glyn Normington wrote:
> 
> The strawman currently says that a superpackage must be defined by the 
> same class loader as its member classes.
> 
> In discussion with Alex, it seems this may be stated too strongly and 
> maybe it should have been phrased in terms of initiating class loaders.
> 
> I'd appreciate a summary of the thinking which led to the statement in 
> the strawman.

If it were allowed for a superpackage SP and a member type T to be loaded 
via different class loaders, we would need to ensure that different class 
loaders having loaded different variants of SP or T cannot lead to holes 
in the type system or to other inconsistencies.

We have not examined this issue in any depth, but at first glance it 
appears similar to the classic class loading problem [1] which lead to 
loading constraints being added to the JVMS [2].

Given that a superpackage and its types are one logical entity, a much 
simpler solution is to have everything defined in one class loader. (Of 
course this says nothing about how class and spkg files are stored. They 
could be stored in a single JAR file or in many different places)

Do you have a use case where that would be a problem?

Andreas.

[1] http://www.bracha.org/classloaders.ps
[2] 
http://java.sun.com/docs/books/jvms/second_edition/html/ConstantPool.doc.html#78621