harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Geir Magnusson Jr." <g...@pobox.com>
Subject Re: [drlvm] The Return of the Hidden Classloader, Part II
Date Wed, 07 Feb 2007 14:06:07 GMT

On Feb 7, 2007, at 7:56 AM, Tim Ellison wrote:

> 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.

Perfect.  I was looking at stuffing it into the SubURLCLassloader  
loadClass, but this is much cleaner.

> 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:

There are two ways I can think of :

A) Have a list of system-loader verboten  (mx4j, xalan, etc...)


B) Two Phase :

1) list of things on the public surface of the Java SE API :


so we can fail-fast for the majority of stuff and then

2) A list of things that the VM knows is allowed because they were  
placed on the bootclasspath or extension classpath by the user.

and if you don't match, it's forbidden.

I actually think that the first way is faster, since the list is  
shorter (at least right now)

So the next question is for the non-static list (i.e. for option A or  
the second phase of B).

This has to come from the VM, as the VM knows, and it's going to get  
messy if you want to do sophisticated things w/ the classloaders and  
such. (aka "OSGi")


I'd like to add a new luni-kernel abstract class :


that has (depending on if we choose A or B) one of

    String[] getAppAllowedSystemLoaderList()   //or something
    String[] getAppDeniedSystemLoaderList()   //or something

that for the Allowed version has an empty list (maybe we put JUnit in  
there...) and for the Denied version has mx4j, xalan

and a class


so and use VMUtility in URLClassloader to get the list.  This way,  
there are no VM changes allowed now, VMs can then provide their own  
o.a.h.k.v.VMUtillity to reflect user-added stuff on bootclasspath and  
extentionclasspath,  and in the future, we can add default  
functionality to VMUtilityBase and use it immediately w/o requiring  
changes to the VMs.

Does this make any sense?


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

View raw message