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

[Andreas Sterbenz]

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?

> 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

> 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()]

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

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.

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?

Andreas.