Sorry for the late reply.
> 1. what version of javaflow?
> 2. what version of jci?
We're working with the trunk version : 1.0-SNAPSHOT for jci-core and
javaflow
Compiled yourself?
> What OS are you testing on?
>
Gentoo Linux - FS ext3.
Maybe the problem is that first time it reads the original bytecode, so
it enhance it and writes the new bytecode; since the class has changed
the second step will notify it, triggering another transformation, and
so on. We should transform all the classes once and then run the FAM.
I'll do more tests on it.
No, no, no... the files on the filesystem level are never getting changed!
Your eclipse creates the .class files, the fam recognizes the new/modified
file and triggers an event. The .class file is getting read, then transformed
IN MEMORY(!!) and provide to the classloader.
Could you please check out jci trunk and run the testcases on that machine?
> Wait a sec ....you don't want to instrument the JavaInterpreter! But
> enhancing classes at build time is a nice addition.
>
Yes it's true. Sorry for the mistake; we instrument the following classes:
Invoker.class
FormInstance.class
AbstractContinuable.class
VarMap.class
You only need to instrument classes that transitivly or directly call out to
Continuation.suspend() to return from the execution. In theory that means
Invoker ->
YourFlow.method ->
FormInstance.show ->
AbstractContinuable.sendPageAndWait ->
Continuation.suspend()
But the Invoker class is a special case an be ignored as it not really
contributes
a change to call stack. So the only classes that require instrumentation are
o FormInstance.class
o AbstractContinuable.class
plus your flow of course ;-)
cheers
--
Torsten
