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
PGP.sig
Description: This is a digitally signed message part
