Re: Infinite loop

[Mark Wielaard]

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