[jsr294-modularity-eg] Strawman for the reflective API

[Glyn Normington]

Andreas Sterbenz <Andreas.Sterbenz at sun.com> wrote on 16/07/2007 09:40:14 
PM:

> Glyn Normington wrote:
> > 
> > Assuming ClassLoader.findSuperpackage is not private, how will it 
> > guarantee to function correctly if application code calls it? The 
> > scenario I have in mind is two threads calling the same class loader 
> > object to find the same superpackage.
> 
> The findSuperpackage() method should only ever be called by the JVM [1]. 

> Because it is declared 'protected', it is not possible for application 
> code to call it at all. It could only be called by a ClassLoader 
> implementation (or code in the same package). That would be a developer 
> error and I expect is likely to be caught in testing.

I agree entirely with the sentiment, but a custom class loader *is* 
application code. We should document that a custom class loader calling 
ClassLoader.findSuperpackage is an error, but I don't understand why we 
would want to take advantage of this and allow findSuperpackage to 
malfunction in this situation. I'd prefer to make fundamental mechanisms 
like this robust (i.e. have a precondition of true).

> 
> Andreas.
> 
> 
> [1] if we think there is a use case for Java code needing to obtain the 
> Superpackage object for a given name, we should add the 
> Superpackage.forName() method I mentioned earlier.

Glyn





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/20070717/095f6def/attachment-0001.html