[jsr294-modularity-eg] Superpackage defining class loader

[Glyn Normington]

I don't have a specific use case where this would be a problem except the 
general use case of someone trying to understand the 294 specification and 
how it relates to class loaders.

I agree that defining a superpackage and its members in a single class 
loader is eminently sensible in most cases and is the only use case 
anticipated in JSR 277, but I don't see why that necessitates a 
restriction to prevent other cases.

I agree that more loading constraints would be needed for a general 
solution, but I don't see why that is a particular issue.

However, I would like to avoid the 294 spec. and the JVMS from needing to 
talk about class loaders when defining the superpackage concept. For me, 
294 is a really important change to Java and getting the concept clean is 
imperative.

Glyn

Andreas Sterbenz <Andreas.Sterbenz at sun.com> wrote on 23/04/2007 17:32:14:

> 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
> 
> _______________________________________________
> jsr294-modularity-eg mailing list
> jsr294-modularity-eg at cs.oswego.edu
> http://cs.oswego.edu/mailman/listinfo/jsr294-modularity-eg






Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 
741598. 
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU





-------------- next part --------------
An HTML attachment was scrubbed...
URL: /pipermail/attachments/20070424/216a49ec/attachment.html