Loading ...
Sorry, an error occurred while loading the content.
 

Re: [junit] Re: Feedback requested: Impending changes to RunListener

Expand Messages
  • Kevin Cooney
    ... Remember, this annotation changes the behavior of JUnit will have when interacting with classes that extend RunListener. It s not simply an indication that
    Message 1 of 30 , Feb 14, 2013
      On Thu, Feb 14, 2013 at 9:27 AM, tibord47 <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 junit@yahoogroups.com, 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 @....
      > >
      > >
      > > 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]
    • tibord47
      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
      Message 2 of 30 , Feb 14, 2013
        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 junit@yahoogroups.com, 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 junit@yahoogroups.com, 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 @....
        > > >
        > > >
        > > > 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]
        >
      Your message has been successfully submitted and would be delivered to recipients shortly.