[jsr294-modularity-eg] Strawman for the reflective API
glyn_normington at uk.ibm.com
Fri Jun 15 06:28:10 EDT 2007
Andreas Sterbenz <Andreas.Sterbenz at sun.com> wrote on 14/06/2007 06:33:06
> Glyn Normington wrote:
> > Some comments on the reflective API strawman:
> > 1. Maybe I'm missing something obvious, but please could you explain
> > rationale for the Superpackage class belonging to the
> > package rather than java.lang?
> The package java.lang.reflect is the package for the core reflection
> 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
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
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
> > driven in the defining class loader of the first class of the
> > superpackage to be loaded?
> Yes, for the reasons stated in
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
> Superpackage.forName(String, ClassLoader) method analogous to
> [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
> 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
> > 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
> 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
> 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
> 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
> 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.
> jsr294-modularity-eg mailing list
> jsr294-modularity-eg at cs.oswego.edu
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