[jsr294-modularity-eg] Strawman for the reflective API
glyn_normington at uk.ibm.com
Tue Jul 17 05:06:59 EDT 2007
Andreas Sterbenz <Andreas.Sterbenz at sun.com> wrote on 16/07/2007 09:40:14
> 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 .
> 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).
>  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.
Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the jsr294-modularity-eg