On Mar 20, 2009, at 2:55 PM, Charles Oliver Nutter wrote:

> I'm not sure how useful getLoadedClasses would even be. Most classes
> load so late that you'd never see them in this list, and since the
> purpose of doing the import is to get access to classes you haven't
> accessed yet...they're almost certain to not be loaded.

Yes, if this is for emulating things like import pkg.*,  
getLoadedClasses is pretty useless.

It sounds like you mainly want the class loader to confess what it  
knows about finding classes, in a way that lets you predict (more or  
less) whether it would load a class of some given name.  (Plus a way  
of enumerating such names.)

Class loaders can do arbitrary magic, so such an API would have to  
have a big Caveat Emptor on it.  Still, a few possibilities suggest  
themselves; see below.

I wonder if there is some way to cobble together the functionality  
from ClassLoader.getResources(pkgName) plus some new functionality (or  
guarantees) on directory URLs and listing.  Again, caveats are needed,  
but something useful might be possible.

-- John

/** Disclose the source(s) that this loader is likely to use in the  
future for resolving class names.
  *  The result is purely advisory, as the loader may actually use  
different sources when actually requested to load a class.
  */
List<URL> ClassLoader.getSourceURLs();

/** Given a package qualifier, return the names (minus the qualifier)  
of all classes which this loader is likely to be able to load in the  
future.
  *  If includeSubpackages, include in the list the names (partially  
qualified) of classes in subpackages also.
  *  Passing the arguments ("", true) will produce a list of al  
loadable classes in all packages, included the anonymous package.
  *  The result is purely advisory, as the loader may actually produce  
different names when actually requested to load a class.
  */
List<String> ClassLoader.listPackageClasses(String package, boolean  
includeSubpackages);

(Actually, List might have to be Enumeration for coherence with  
existing CL methods.)


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "JVM 
Languages" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to 
[email protected]
For more options, visit this group at 
http://groups.google.com/group/jvm-languages?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply via email to