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

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

Expand Messages
  • Kevin Cooney
    ... 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
    Message 1 of 30 , Feb 14, 2013
    • 0 Attachment
      On Thu, Feb 14, 2013 at 8:38 AM, David Saff <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]
    • tibord47
      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
      Message 2 of 30 , Feb 14, 2013
      • 0 Attachment
        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 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]
        >
      • 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 3 of 30 , Feb 14, 2013
        • 0 Attachment
          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 4 of 30 , Feb 14, 2013
          • 0 Attachment
            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.