Re: Re: Feedback requested: Impending changes to RunListener

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.  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).  However, the document
assumes that declaring a marker interface ThreadSafeRunListener _would_
break the client.  Is that true?  Does FooListener fail at bytecode
verification because the verifier wants to make sure that it implements all
of ThreadSafeRunListener's methods?

Thanks,

   David


On Thu, Feb 14, 2013 at 7:10 AM, tibord47 <[email protected]> wrote:

> **
>
>
> Hi All,
>
> I am open for declaring @ThreadSafe in JUnit bundle due to the reasons
> like the other artifacts are project or person specific in Maven central
> and license issues.
>
> But I am not open for @Concurrent. The @ThreadSafe is the strongest
> terminology. One day if we will have both, it will be just confusing.
>
> If we now take over Stephen's class javadoc, we have to copy the Apache
> License.
>
> I think we do not have to follow the jcip either Stephan's definition of
> thread-safety in the annotation. We can follow the general definition "to
> be free of data race conditions". Simply see the wikipedia. And what this
> definition really means has to be specified in the class which allows
> thread-safety treatments.
>
> http://stackoverflow.com/questions/1999122/how-to-define-threadsafe
>
> Therefore the RunListener has to say in javadoc that it can be annotated
> @ThreadSafe if its use pattern satisfies reasonable expectations of thread
> safety. So RunListener allows using this annotation.
>
> Now we can talk about these expectations. I think they will be these and
> maybe you can add yours:
>
> + If RunListener is created in T1, values in the variables initialized by
> the constructor which are (indirectly) read in public methods have proper
> visibility;
> + All public methods in RunListener can be called in T2, or more threads
> at the same time;
> + RunListener must not achieve non-deterministic nor invalid state.
>
> What is your opinion about this approach?
>
> Cheers,
> Tibor
>
>
> --- In [email protected], Kevin Cooney wrote:
> >
> > I don't think we should use a re-packaged implementation of
> > jcip-annotations. Creating a new "clean room" implementation just so we
> can
> > use one annotation in JUnit seems to violate KISS.
> >
> > Although I am the one who originally suggested we use ThreadSafe from
> > jcip-annotations, I no longer feel that way.
> >
> > I think we should either have a JUnit-specific annotation or a create an
> > abstract subclass of RunListener. If we create our own annotation, I
> > strongly feel that it should not be named ThreadSafe (see my comments in
> > the Google docs page for more details)
> >
> >
> https://docs.google.com/document/d/1OeE5OUKgtkKHeQuA7bKldBTk-yQ83bH6BHokwifCPrE/edit#
> >
> > -- Kevin
> >
> > On Wed, Feb 13, 2013 at 4:18 PM, tibord47 wrote:
> >
> > > **
> > >
> > >
> > > Hi Stephen,
> > >
> > > The correct groupId is com.github.stephenc.jcip.
> > > I already intalled and used the junit lib 4.12-snapshot in other
> project.
> > >
> > > The text in @ThreadSafe is similar to the one in original jcip.
> > > Although i would omit mentioning modifier "public" since the all
> problem
> > > of thread safety is in fields which are read or write in critical
> > > section=methods/constructor. So the modifier may not necessarily be
> public.
> > > It can be also protected, etc.
> > > So better not to mention any modifier in the text.
> > >
> > > Let's wait for other repliers and then to make a new deployment.
> > >
> > > Cheers,
> > > Tibor
> > >
> > >
> > > --- In [email protected], Stephen Connolly wrote:
> > > >
> > > > To allow for the removal of licensing concerns, I have clean-room
> reverse
> > > > engineered the jcip-annotations as well:
> > > > https://github.com/stephenc/jcip-annotations
> > > >
> > > > Should be available from Central in the next 1-8 hours
> > > >
> > > >
> > > > com.github.stephenc
> > > > jcip-annotations
> > > > 1.0-1
> > > >
> > > >
> > > > This should be a drop in replacement for
> > > >
> > > >
> > > > net.jcip
> > > > jcip-annotations
> > > > 1.0
> > > >
> > > >
> > > > But if it isn't please let me know and I can fix and roll a 1.0-2
> > > >
> > > >
> > > > On 13 February 2013 09:17, Stephen Connolly
> > > > wrote:
> > > >
> > > > >
> > > > >
> > > > >
> > > > > On 13 February 2013 01:17, Kevin Cooney wrote:
> > > > >
> > > > >>
> > > > >>
> > > > >> On Tue, Feb 12, 2013 at 2:14 PM, tibord47 wrote:
> > > > >>
> > > > >>> **
> > >
> > > > >>>
> > > > >>>
> > > > >>> Hi all,
> > > > >>>
> > > > >>> ok, so in that case the standard javax annotations cannot be
> used.
> > > > >>>
> > > > >>> Other options are jcip and proprietary one.
> > > > >>>
> > > > >> There are a few other options that were suggested. I've summarized
> > > them
> > > > >> all here:
> > > > >>
> > > > >>
> > > > >>
> > >
> https://docs.google.com/document/d/1OeE5OUKgtkKHeQuA7bKldBTk-yQ83bH6BHokwifCPrE/edit#
> > > > >>
> > > > >> Feel free to add comments if I missed something. If you don't
> have a
> > > > >> Google account (or even if you do) feel free to continue to
> comment
> > > here.
> > > > >>
> > > > >>>
> > > > >>> I vote for jcip since the license allows us to use a dependency.
> > > > >>>
> > > > >> Stephen indicated a concern with the jcip-annotations license.
> > > Hopefully
> > > > >> he (or someone else with a concern) can explain why the license is
> > > > >> problematic.
> > > > >>
> > > > >
> > > > > I indicated that there may be a concern with the license and you'd
> > > want to
> > > > > check.
> > > > >
> > > > > We had (at former employers) an issue with the findbugs annotations
> > > > > (LGPL), so I created
> https://github.com/stephenc/findbugs-annotationsas
> > > > > a clean-room reverse engineered implementation (Apache License v2)
> of
> > > the
> > > > > same annotations specification.
> > > > >
> > > > > We weren't using the jcip-annotations, so those were not subject
> to the
> > > > > lawyers reviewing.
> > > > >
> > > > >
> > > > >>
> > > > >> -- Kevin
> > > > >>
> > > > >>
> > > > >
> > > >
> > > >
> > > > [Non-text portions of this message have been removed]
> > > >
> > >
> > >
> > >
> >
> >
> > [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/