You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by WHIRLYCOTT <ph...@whirlycott.com> on 2005/01/29 23:09:47 UTC
[javaflow] test cases in junit?
Torsten -
Any objections to receiving test cases using junit?
phil.
--
Whirlycott
Philip Jacob
phil@whirlycott.com
http://www.whirlycott.com/phil/
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [javaflow] test cases in junit?
Posted by Torsten Curdt <tc...@apache.org>.
>>> * 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
Re: [javaflow] test cases in junit?
Posted by WHIRLYCOTT <ph...@whirlycott.com>.
Torsten Curdt wrote:
>
>> * 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.
> Please have a look into the one I've
> committed. Continueing from the very
> same continuation is totally ok!
>
> Keep the tree of continuations in mind!
Ok, thanks for correcting me.
>
>> * In the TODO file, you mention something about removing the Continuable
>> and ContinuationCapable marker interfaces. Can you please elaborate on
>> the reasons behind that?
>
>
> 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. And I think just tagging the rewritten class
with this interface is pretty transparent, no?
phil.
--
Whirlycott
Philip Jacob
phil@whirlycott.com
http://www.whirlycott.com/phil/
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [javaflow] test cases in junit?
Posted by Torsten Curdt <tc...@apache.org>.
Phil,
thanks for the patch! I did apply some of
it ...see the comments inline
> Some notes:
>
> * The simplelog setup wasn't working at all for me for anything less
> than info, so I added log4j into the project.xml. Works fine now. Not
> sure if you were having a similar problem? junit is also added to
> project.xml.
I would prefer not add an dependency to log4j.
Should be up to the user to provide the prefered
logging.
Just add
-Dorg.apache.commons.logging.Log=org.apache.commons.logging.impl.SimpleLog
to your jvm startup and it should work fine.
> * There are some references to /home/tcurdt in .classpath. I didn't
> touch them. Does this even belong in svn?
Yeah, it's the eclipse classpath file.
Should be gone now.
> * 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"?!
> * Added some serialVersionUID fields to Serializable classes.
This is only required when you need
versioning of serializable classes.
We don't need that.
> * The test case causes an exception to be thrown and tests for it, so be
> aware of that when you see the stacktrace in the output.
I've seen what you were trying in
the testcase. But that was not right.
Please have a look into the one I've
committed. Continueing from the very
same continuation is totally ok!
Keep the tree of continuations in mind!
> * In the TODO file, you mention something about removing the Continuable
> and ContinuationCapable marker interfaces. Can you please elaborate on
> the reasons behind that?
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...
> Just starting off small for now - more soon.
Cool bananas!
cheers
--
Torsten
Re: [javaflow] test cases in junit?
Posted by WHIRLYCOTT <ph...@whirlycott.com>.
Ok, here's a start, anyway.
Some notes:
* The simplelog setup wasn't working at all for me for anything less
than info, so I added log4j into the project.xml. Works fine now. Not
sure if you were having a similar problem? junit is also added to
project.xml.
* There are some references to /home/tcurdt in .classpath. I didn't
touch them. Does this even belong in svn?
* 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.
* Added some serialVersionUID fields to Serializable classes.
* The test case causes an exception to be thrown and tests for it, so be
aware of that when you see the stacktrace in the output.
* In the TODO file, you mention something about removing the Continuable
and ContinuationCapable marker interfaces. Can you please elaborate on
the reasons behind that?
Just starting off small for now - more soon.
phil.
Torsten Curdt wrote:
>> Any objections to receiving test cases using junit?
>
>
> Phil, of course not! :)
>
> ...actually it was my plan using junit for that.
>
> cheers
> --
> Torsten
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
--
Whirlycott
Philip Jacob
phil@whirlycott.com
http://www.whirlycott.com/phil/
Re: [javaflow] test cases in junit?
Posted by Torsten Curdt <tc...@apache.org>.
> Any objections to receiving test cases using junit?
Phil, of course not! :)
...actually it was my plan using junit for that.
cheers
--
Torsten
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org