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:10:05 GMT
correction below...

On Feb 7, 2007, at 9:06 AM, Geir Magnusson Jr. wrote:

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

that extends VMUtilityBase

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

"there are no VM changes *required* now"

> 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