[concurrency-interest] JCIP annotations: @GuardedBy

Philip Aston philipa at mail.com
Sun Apr 6 03:48:20 EDT 2014


Thanks Tim.

It's good to know I'm not missing something.

- Phil

On 05/04/14 16:13, Tim Peierls wrote:
> It's a fair cop, but society is to blame -- or rather, our sense that
> the society of Java developers, at the time that JCiP was written, was
> not ready for a more elaborate system of annotations than what we
> settled on. (It's not that we weren't aware of such systems; Doug Lea
> had many, many draft proposals.)
>
> We were concerned back then that forcing a set of complicated
> semantics on users would guarantee that no one except experts would
> use them. We thought, and I still think, that there is pedagogical
> value in this simplified set beyond even the obvious practical
> benefits of FindBugs support.
>
> Remember, too, that although JSR 308 existed at the time, we couldn't
> rely on its inclusion in the platform. (Good thing we didn't!)
>
> The book's treatment of this subject is out of date, superseded by JSR
> 305. It might be time to update the specs in
> javax.annotation.concurrent. Purists would object, I'm sure, but just
> by expanding the syntactical possibilities of the String value of
> @GuardedBy one could cover a lot of ground with a minimum of fuss.
>
> --tim
>
>
> On Sat, Apr 5, 2014 at 10:08 AM, Philip Aston <philipa at mail.com
> <mailto:philipa at mail.com>> wrote:
>
>
>     Does anyone use the JCIP annotations? What's your take on the
>     following?
>
>     We use the Java Concurrency In Practice annotations. This is
>     mostly a documentation discipline, but it also helps findbugs
>     <http://findbugs.sourceforge.net/manual/annotations.html> tell us
>     not to be stupid.
>
>     The class level @Immutable / @ThreadSafe / @NotThreadSafe are
>     useful and self explanatory.
>
>     Unfortunately, interpreted strictly according to JCIP Appendix A,
>     @GuardedBy is less so. It is not expressive enough to cover common
>     locking patterns. E.g. this might look right to the casual eye:
>
>     class Foo {
>       @GuardedBy("bah")
>       final Collection bah = new ArrayList();
>     }
>
>     but @GuardedBy refers to the field bah, which is final so doesn't
>     need a guard. There's no way to indicate access to the collection
>     itself should be guarded - e.g. that you must hold the lock on bah
>     before iterating over the collection.
>
>     The JCIP book ignores this distinction. E.g. Listing 11.6, page
>     236. I find this a rare flaw in an otherwise very precise book.
>     That "its obvious what was intended" is a poor defence since the
>     whole point of the annotations is to specify intent.
>
>     Maybe Java 8 / JSR 308 is the answer and I should write something
>     like:
>
>         @Target({ ElementType.FIELD, ElementType.METHOD,
>     ElementType.TYPE_USE })
>         public @interface GuardedBy2 {
>             String value();
>         }
>
>         final Collection bah = new @GuardedBy2("self") ArrayList();
>
>     but I'm on Java7, so
>
>         final Collection bah = new /* GuardedBy("self") */ ArrayList();
>
>     for now.
>
>     Thoughts?
>
>     - Phil
>
>     _______________________________________________
>     Concurrency-interest mailing list
>     Concurrency-interest at cs.oswego.edu
>     <mailto:Concurrency-interest at cs.oswego.edu>
>     http://cs.oswego.edu/mailman/listinfo/concurrency-interest
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20140406/8dd11f6b/attachment.html>


More information about the Concurrency-interest mailing list