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

or

B) Two Phase :

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

     java.
     javax.
     etc

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")

So...

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

   o.a.h.kernel.vm.VMUtillityBase.java

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

   o.a.h.kernel.vm.VMUtility.java

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?

geir

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