On Wed, 2005-11-09 at 14:12 -0600, Archie Cobbs wrote: > Stuart Ballard wrote: > > Seems like we could remove VMClass.getClassLoader altogether then > > since it's public and static in VMStackWalker? > > Yes, I suppose so...
I can imagine a vm optimizing VMClass.getClassLoader() differently from VmStackWalker.getClassLoader(). So I would keep them both just in case. Unless you think that is really messy or a really far fetched optimization oppertunity. > > On the other hand, > > should it be public in VMStackWalker? Is that ok from a security > > standpoint? > > Yes.. all the other methods in there are too. VMStackWalker can only > be used by classes loaded via the boot loader (see comment > at the top). I must admit that it took me also a bit of thinking why this is safe. A user defined class loader loadClass() method needs to handle SecurityManager.checkPackageAccess() when a security manager is installed. And since any class can only access another class through loading the class directly or indirectly through its own class loader this can be used to deny any access to classes not loaded by the bootstrap class loader. See the GNU Classpath ClassLoader createSystemClassLoader() method for an example of how this works. Cheers, Mark -- Escape the Java Trap with GNU Classpath! http://www.gnu.org/philosophy/java-trap.html Join the community at http://planet.classpath.org/
signature.asc
Description: This is a digitally signed message part
_______________________________________________ Classpath mailing list [email protected] http://lists.gnu.org/mailman/listinfo/classpath
