harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tim Ellison <t.p.elli...@gmail.com>
Subject Re: [drlvm] The Return of the Hidden Classloader, Part II
Date Wed, 07 Feb 2007 12:56:16 GMT
Geir Magnusson Jr. wrote:
> On Feb 7, 2007, at 7:00 AM, Tim Ellison wrote:
>> Rather than a hidden class loader we can filter the app classloader's
>> delegation to the bootclassloader so it only gets an opportunity to load
>> API types.  Let me have a quick play ...
> 
> Yes - that's the same concept, but I can see how that's going to be
> easier, because there's less machinery needed to figure out who is
> asking.  If you don't mind, I'll take a wack.

The hack I was thinking of is to override loadClass in URLClassLoader,
and put a filter in there to only delegate to the parent if you are the
system (i.e. what I would call the 'application') class loader and the
package is one that you want to pick up.

My first pass through only allows JSE API types, but that likely won't
be great as it doesn't account for people putting JUnit etc. on the
bootclasspath and expecting it to work out.  We may need to flip it
around and have a list of explicitly hidden packages:


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);
}


Mime
View raw message