Re: Re: Feedback requested: Impending changes to RunListener

On Thu, Feb 14, 2013 at 8:38 AM, David Saff <[email protected]> wrote:

> Hi, all.
>
> Kevin, thank you very much for the summary document.  I think that a
> JUnit-specific annotation, which is not name-confusable with a standard
> like @ThreadSafe, seems to be a pretty clear winner.  If we feel strongly
> that it should remain consonant with @ThreadSafe, we could make it a static
> inner annotation, and reference it as @RunListener.ThreadSafe.


I'm personally find with that as long as the JavaDoc for the annotation
makes it clear that a RunListener implementation annotated with that
interface will be treated differently than one not annotated with that
interface when addListener() and removeListener() is called.



>  That might
> also have the advantage of making clear that it's a single-purpose
> annotation (I'd rather not, at this point, start speculatively figuring out
> what other interfaces might try to pun meanings onto a general-purpose
> ThreadSafe annotation)
>
> I'm a little curious about the third-party library implementation.  Let's
> say I write a package FooTest which is compiled against JUnit 4.12, and it
> contains a FooListener I'd like to mark threadsafe.  A client wants to use
> it with JUnit 4.11 (she knows she won't get the concurrent performance
> boost, but wants it to just work).  The document seems to assume that if
> FooListener has a RunListener.TheadSafe annotation, then our client won't
> have a problem (unless, likely, she actually tries to instantiate all of
> the annotations from FooListener in her own code).


Correct as of JDK 1.5.0_06. See
http://stackoverflow.com/questions/3567413/why-doesnt-a-missing-annotation-cause-a-classnotfoundexception-at-runtime

It sounds that if the client wants to write code that extends FooListener
then JUnit 4.12 will need to be on the compile-time classpath



> However, the document
> assumes that declaring a marker interface ThreadSafeRunListener _would_
> break the client.  Is that true?


I believe it would result in a NoClassDefFoundError exception. It should be
easy to verify.

Note that it may be hard to write a library that has a compile-time
dependency on JUnit 4.12 while being runtime compatible with 4.11 for other
reasons.

 Does FooListener fail at bytecode
> verification because the verifier wants to make sure that it implements all
> of ThreadSafeRunListener's methods?
>

That would be my guess.

-- Kevin


[Non-text portions of this message have been removed]



------------------------------------

Yahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/junit/

<*> Your email settings:
    Individual Email | Traditional

<*> To change settings online go to:
    http://groups.yahoo.com/group/junit/join
    (Yahoo! ID required)

<*> To change settings via email:
    [email protected] 
    [email protected]

<*> To unsubscribe from this group, send an email to:
    [email protected]

<*> Your use of Yahoo! Groups is subject to:
    http://docs.yahoo.com/info/terms/