Re: Feedback requested: Impending changes to RunListener

David, I can confirm that running annotated listener in 4.11 and compiled with 4.12 does not throw exception. So the annotation is winner in my eyes.

Regarding the static inner annotation in RunListener, this would mean that other classes which will maybe later need the same name of annotation will just duplicate again.

Cheers,
Tibor


--- In [email protected], Kevin Cooney  wrote:
>
> On Thu, Feb 14, 2013 at 8:38 AM, David Saff  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/