commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Torsten Curdt <tcu...@apache.org>
Subject Re: [javaflow] class loader
Date Wed, 03 Aug 2005 09:54:57 GMT

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

I have been using other code rewriting classloaders
as system classloaders. No problem. I think what
you are referring to is the bootstrap classloader.


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

Ah ...no idea about this TestCaseClassLoader.
Never used it before. I think it depends on
the delegation model whether you need those
exclusions or not. If it's parent-first you
don't need it.

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

Ah ...now I see ...because the parent
cannot load the class anymore. ok.

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

No worries ...just go ahead

cheers
--
Torsten


Mime
View raw message