"Geir Magnusson Jr." <[EMAIL PROTECTED]> wrote on 07/02/2007 15:36:01:
>
> On Feb 7, 2007, at 7:56 AM, Tim Ellison wrote:
>
> >
> >
> > protected synchronized Class<?> loadClass(String className,
> > boolean resolveClass) throws ClassNotFoundException {
> >
> > if (this == getSystemClassLoader()) {
> > int index = className.lastIndexOf('.');
> > String pkgName = index > 0 ? className.substring(0,
> > index) : "";
> >
> > System.out.println("Checking visibility for " + pkgName);
> > if (!pkgName.startsWith("java.") && !pkgName.startsWith
> > ("javax.")
> > && !pkgName.startsWith("org.ietf.jgss")
> > && !pkgName.startsWith("org.omg")
> > && !pkgName.startsWith("org.w3c.dom")
> > && !pkgName.startsWith("org.xml.sax")) {
> > throw new ClassNotFoundException(className);
> > }
> > }
> > return super.loadClass(className, resolveClass);
> > }
> >
>
> Revealing my ignorance about java classloading :
>
> Why wouldn't we need to care about the caller? (This is what had me
> going into the VM first...) What if loadClass() is getting called by
> an implementation class, which does need access to the internal
> packages that are prohibited for app classes?
If the VM needs to resolve a reference from class A to class B, it will
call loadClass on the defining class loader of A. (The defining class
loader of A is the class loader whose defineClass created class A. You
can get the defining class loader of a class via Class.getClassLoader,
although the bootstrap class loader is represented as null.)
Back to your questions. An implementation class will have been defined
by the bootstrap class loader so if it needs to reference other classes,
the VM will resolve those references using the bootstrap class loader.
so you don't need to worry about the caller as the application class
loader (AKA the system class loader) won't get a look in when
implementation classes are being resolved.
Glyn
PS. I subscribed to this list earlier in order to post. But my post
didn't get sent back to me and I'm not using gmail.
