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

[Glyn Normington]

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

> Glyn Normington wrote:
> > 
> > Some comments on the reflective API strawman:
> > 
> > 1. Maybe I'm missing something obvious, but please could you explain 
the 
> > rationale for the Superpackage class belonging to the 
java.lang.reflect 
> > package rather than java.lang?
> 
> The package java.lang.reflect is the package for the core reflection 
API. 
> The Superpackage class will be part of that API. The reason Class and 
> Package are in java.lang is for historical reasons and not by design.
> 
> Do you think there is a disadvantage to putting it into 
java.lang.reflect?

I am probably wrong to think this way, but I think of java.lang.reflect as 
being specifically for reflection whereas stuff in java.lang I think of as 
being basic Java concepts. So I would hope that a modularised JRE could 
avoid loading java.lang.reflect unless the application needed to do 
reflection. I guess this is probably impractical as reflection is such a 
core concept in Java, but at least you have some idea of where I'm coming 
from.

I don't have an issue now I understand the rationale.

> 
> > 2. ClassLoader.findSuperpackage does not appear to follow the normal 
> > rules of class loader delegation as there is no loadSuperpackage 
> > analogue of loadClass. Is this because we expect findSuperpackage to 
be 
> > driven in the defining class loader of the first class of the 
> > superpackage to be loaded? 
> 
> Yes, for the reasons stated in 
> http://altair.cs.oswego.edu/pipermail/jsr294-modularity-eg/2007-
> May/000070.html

I don't see any relevant reasons in that post. Your "yes" was sufficient, 
but please elaborate if there's more insight to be had from the post.

> 
> > If so, what happens if a superpackage needs 
> > to be loaded before any of its member classes, e.g. for the purpose of 

> > reflection? Couldn't it then end up being loaded in the 'wrong' class 
> > loader relative to where member classes will be loaded?
> 
> The assumption is that a Superpackage object would not needed before its 

> classes are loaded. If we feel that assumption is incorrect, we can add 
a 
> Superpackage.forName(String, ClassLoader) method analogous to 
Class.forName().
> 
> [Note that Class.forName() is preferred over classLoader.loadClass() 
> because it works consistently for bootstrap classes and because the JVM 
> can record the classloader as the initiating classloader for the 
resulting 
> class in its cache. This is not the case if applications call 
> classLoader.loadClass()]

Ok.

> 
> > 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.

> 
> As for multiple concurrent calls, a findLoadedSuperpackage() method to 
> access the cache would not really help as there is a race condition 
> between checking the cache and defining the superpackage. The solution 
for 
> this issue will depend on what the solution for the multi-threaded class 

> loading support in JDK 7 looks like. We should wait for that proposal 
and 
> then reevaluate our assumptions.

Ok. At least we've aired the issue.

> 
> In other words, it does not seem necessary to expose the cache as a 
public 
> API. Do you feel there is a situation where that is needed?

Well, concurrent class loading scenarios would seem to require it, but I'm 
happy for this to be fleshed out later after the class loader 
rearchitecture work is firmer.

Glyn

> 
> Andreas.
> 
> _______________________________________________
> 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/20070615/101c9aae/attachment-0001.html