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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
