Re: Feedback requested: Impending changes to RunListener

I am still thinking of the inner staff. You know that it's not recommended convention to make a class inner unless it uses this pointer of the top class.
Then it should be public annotation in the same package.

Hm?

--- In [email protected], Kevin Cooney  wrote:
>
> On Thu, Feb 14, 2013 at 9:27 AM, tibord47  wrote:
> 
> > **
> >
> >
> > 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.
> >
> Remember, this annotation changes the behavior of JUnit will have when
> interacting with classes that extend RunListener. It's not simply an
> indication that the listener is thread-safe (though your listener would
> have to be thread-safe to use this annotation). See my comments in
> http://goo.gl/6HBNV to see other reasons why I think a top-level JUnit
> ThreadSafe annotation would be problematic
> 
> I'm personally not too worried about what might happen if we need to think
> about indicating the thread-safety of extension points somewhere else in
> JUnit. We could easily support multiple annotations in the future if we
> need to, and when that time comes, perhaps JSR-305 will be more mature.
> 
> -- Kevin
> 
> 
> >
> >
> > 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]
> > >
> >
> >  
> >
> 
> 
> [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/