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

Glyn Normington glyn_normington at uk.ibm.com
Wed Jun 27 10:10:57 EDT 2007


Hi Andreas

Andreas Sterbenz <Andreas.Sterbenz at sun.com> wrote on 27/06/2007 08:07:35 
AM:

> Hi,
> 
> there have been no further comments about this proposal in the last week 

> and I believe the issues raised by the earlier comments about it have 
been 
> resolved. As such, I assume there is consensus to move forward with this 

> strawman. Of course we will continue to evolve and refine it.
> 
> If you disagree, please let me know.

There was one loose end I'd like tidying up.

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 original discussion is below.

Glyn

Andreas Sterbenz <Andreas.Sterbenz at sun.com> wrote on 14/06/2007 06:33:06 
PM:

> > 3. There is no ClassLoader.findLoadedSuperpackage method analogous to 
> > findLoadedClass, so what enables findSuperpackage to return consistent 

> > results if it is called twice, either serially or concurrently, with 
> > identical input parameters? For example, suppose two threads load 
class 
> > files (in a single class loader) belonging to a superpackage which has 

> > not yet been loaded. We need to ensure that we end up with one 
> > Superpackage instance and that both class loads succeed and the 
> > resultant class instances refer to the Superpackage instance.
> 
> That is certainly important.
> 
> The JVM would ensure that findSuperpackage() is never called twice 
> serially. If we add Superpackage.forName(), the JVM would also check the 

> cache first before calling findSuperpackage().

I don't see how the JVM can actually prevent application code calling 
findSuperpackage twice serially, although it could certainly police its 
own behaviour. I know we don't want application code to call 
findSuperpackage, but we'd have to make the method private to be sure to 
prevent that.





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/20070627/6995d90e/attachment.html 


More information about the jsr294-modularity-eg mailing list