commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Torsten Curdt <>
Subject Re: [javaflow] class loader
Date Tue, 02 Aug 2005 17:31:43 GMT

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


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

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

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

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

> Personally, I find the current ContinuationClassLoader bit too  
> error-prone. Because the parent ClassLoader can always load the  
> same class that a child ContinuationClassLoader can load, you can  
> easily get two Class objects that have the same name if you are not  
> careful.

Well ...we cannot necessarily prevent classes
from being loaded through the parent classloader.

> In my day job, I saw several JAXB users who face this kind of  
> issues while using JAXB in JUnit, and these issues are very hard to  
> diagnose.

Sure ...classloader stuff is always tricky.

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

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


View raw message