Re: Feedback requested: Impending changes to RunListener

"tibord47" <[email protected]>
Newsgroups gmane.comp.java.junit.user
Message-ID <[email protected]>
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]
>




------------------------------------

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/
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.