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

Re: Feedback requested: Impending changes to RunListener

Expand Messages
  • 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 1 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.