[jsr294-modularity-eg] Strawman for the reflective API
Andreas.Sterbenz at Sun.COM
Thu Jun 14 13:33:06 EDT 2007
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
> 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
> 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?
More information about the jsr294-modularity-eg