* I added a ContinuationException class that can be thrown to clients using this code instead of stuff like java.lang.reflect.InvocationTargetException that is dependent on the underlying bytecode toolkit.
That class was missing in your patch. Besides I am wondering what you mean by "dependand on the bytecode toolkit"?!
There was a note in TODO about investigating using ASM instead of BCEL. Without even looking in detail at ASM, my guess is that it will throw different exceptions than BCEL when manipulating the bytecode, etc. My idea was that we could throw a ContinuationException instead of the underlying FooException that either BCEL or ASM uses to insulate any calling classes from having to change in the event of a switch from BCEL to ASM.
The java.lang.reflect.InvocationTargetException comes from the use of the reflection API. And maybe it's the only one that we have to catch at that stage anyway.
I haven't really made up my mind whether I would like to see an Exception in the suspend() signature. ..but I tend to say we don't need one. If something goes wrong at that stage -and it is not due to reflection- something is heavily broken and throwing a specific exception probably won't help much.
...but I am open to suggestions!
The Continuable marks classes that should be rewritten. The ContinuationCapable mark classes that have been rewritten. IMO this can all go away.
We could define that on a package scope. E.g. via regexp.
Going for a decend callflow analyses would even figure out the needed rewrites by itself. Might be some work though...
I think I understand the reason why both of these interfaces exist. However, if the intent is to be able to use Continuation.suspend() within any class without having to implement Continuable on that class, then maybe just do away with Continuable and keep ContinuationCapable as the marker for that class after it has been rewritten.
What benefit does the regex approach provide? Callflow analyses seems like it could be messy.
IMO a callflow analysis would be the cleanest possible way. ...we would only need to wrap the method calls that actually have an impact on the continuation. Only methods that possibly could call suspend() need to be taken care of.
If we had the entry point we should be able to find out whether we need to instrument the class without specifing any additional information.
And I think just tagging the rewritten class with this interface is pretty transparent, no?
...it is straight forward for sure. IIRC Stephan introduced ContinuationCapable. Need to check why this was necessary - we were running without beforehand.
cheers -- Torsten
signature.asc
Description: OpenPGP digital signature
