commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kohsuke Kawaguchi ...@kohsuke.org>
Subject Re: [javaflow] class loader
Date Wed, 03 Aug 2005 00:43:18 GMT
Torsten Curdt wrote:
>> I noticed that in ContinuationClassLoader you aren't actually using  
>> the marker interface to decide what to instrument any more. Is this  
>> by design? I also noticed a similar comment in the TODO file.
> 
> Yes, I am no big fan of empty marker interfaces.
> I'd prefer a configuration approach.
> 
>> If so, I can remove the Continuable interface.
> 
> Sure

OK.

>> I still see some value in retaining the ContinuationCapable  
>> interface, as this seems to be something we can use for detecting  
>> errors at runtime. But since ContinuationCapable doesn't need to be  
>> visible to users, I wonder if we can move it to the bytecode  
>> subpackage.
> 
> Makes sense, too ...maybe *that* interface
> should be called Continuable then. WDYT?

Will make that change, too.


>> Another thing about ContinuationClassLoader. Right now this class  
>> is hard-coded to recognize the javaflow test packages, but this  
>> needs to be parameterized.
> 
> Yes, that needs to change
> 
>> Also, in JUnit, the list of "excluded packages" can be read from a  
>> data file [1]. I suggest we implement something like that. I don't  
>> think it makes sense for this file to be a property file, so I  
>> think we can just read this as an UTF-8 encoded text file where  
>> each line specifies a new mask. Let me know how you think about me  
>> making those changes.
> 
> Not sure how...that's why I haven't done
> it yet. I'd rather like to use a more
> sophisticated configuration approach.
> 
> Usually I love the configuration classes
> from Avalon ...but I don't want to have
> that dependency.
> 
> ..question is also how it can be handled
> when the classloader is being used as
> system classloader.

I don't think we can even install ContinuationClassLoader as the system 
class loader. I thought the system class loader is set up by JVM before 
any Java code runs.



>> BTW, I found this JUnit implementation interesting. It doesn't seem  
>> to exclude any of the java.* or org.w3c.*, but it must be clearly  
>> working.
> 
> But it does...
> 
>      private String[] excludeFromLoading = {
>          "java.",
>          "javax.",
>          "sun.",
>          "org.xml.",
>          "org.w3c.",
>          "org.apache.commons.logging"
>      };
> 
> ..only the compiling one does not because
> it's using parent-last delegation and the
> repository of classes is restricted to the
> user's classes.

No, I meant that the JUnit TestCaseClassLoader doesn't have an exclusion 
list like you have in ContinuationClassLoader. That must mean that 
somehow the explicit exclusion code isn't necessary for things to work 
correctly. I was wondering why.




>> For this reason, I wonder if we can have another ClassLoader that  
>> works more like a traditional URLClassLoader --- you tell it a set  
>> of locations to look at, then the class loader loads a class file  
>> from it with byte-code instrumentation. This requires a developer  
>> to have separate location for a host and the code that runs inside  
>> the continuation environment, but it eliminates a danger of having  
>> two copies of the same class.
> 
> We should be able to achieve the same by
> restricting the classloader to those
> included packages. Don't you think?
> 
> I am not yet convinced that a separate
> location is that convenient.

In the scenario I explained in the previous e-mail, the benefit that the 
separate location brings is that you get NoClassDefError for Y instead 
of strange ClassCastException trying to cast Y' into Y.

NoClassDefError tends to happen a lot earlier than ClassCastException, 
and it's usually easier for people to grok.


>> URLClassLoader isn't reusable for us, but I think we can start from  
>> AntClassLoader.
> 
> Well ...if you really think that's
> required. As long as it works... :)

I think I'll implement it, because I need it anyway. If eventually you 
decide that you don't like it, we can talk.

-- 
Kohsuke Kawaguchi

---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


Mime
View raw message