[JSR308] Concurrency annotations on blocks

[Tom Ball]

Eugene Kuleshov wrote:
> Tom Ball wrote:
>>>  I can't speak for Intel, but from my practice, one example also not 
>>> mentioned in Java Concurrency in Practice is properties of the 
>>> locking. For instance read or write lock, optimistic vs. eager 
>>> locking. It is too coarse grained to express those on the method 
>>> level only.
>> Wouldn't checking the java.util.concurrent class type or method usage 
>> tell you that?  I'm not arguing that those are important things to 
>> check, but am just trying to understand what the annotation adds that 
>> isn't already clearly expressed in the code.
>  Probably. But only if those locks are used.

Which they should be, if clients need that sort of functionality. 
Annotations aren't supposed to be used instead of good code.  I believe 
that only a very small minority of Java developers can write better 
concurrency-support code than the EG contributed to the Java platform (I 
certainly can't), so it isn't reasonable to add a language feature which 
only that minority can use correctly.  The feature can be justified for 
other reasons, but I don't think you make your case with this one.

I guess what I was really asking is for specific benefits to adding a 
feature that substantially out-weighs the costs everyone has previously 
noted.  I want to be sold (I'd love greatly improved early 
bug-catching), but need more specifics on what we'll get in exchange for 
making the Java language more complicated.  The for-each sale was made 
by the promise that for a small, legible syntax change we get fewer 
broken for loops, for example.  I am looking for, and am very willing to 
help draft, an "ohmygosh I gotta have this now!" list of benefits that 
can be quickly tooled for use by mainstream developers.  The EG vote 
gets into the client's office to make a sales pitch, but in no way 
guarantees the sale to the Java community.

Tom

>  I found that many developers still prefer to use synchronized blocks. 
> So, construct like this:
> 
>  synchronized(mutex) {
>    for(Item item : items) {
>      ...
>    }
>  }
> 
>  can be either safe or unsafe, depends if code in the loop changes items 
> or not. You can say that we can mark Item type as @Immutable or 
> @ThreadSafe (if we allow annotations on local variables), but it won't 
> have exactly the same meaning. Also, for there read lock it is allowed 
> to have multiple readers, while eager write lock imply single owner.
> 
>  Another potential use case for block annotations is to express behavior 
> of the  code on the callee side. For instance @Async annotation can be 
> used if callee is not interested in the immediate result. Right now it 
> would require to use concurrent executor API or some Aspect Oriented 
> constructs to express something like that.
> 
>  I am well aware of the Sun's position on AOP, but it still worth to 
> mention that annotations on code blocks would really help to manage 
> caller side join points and allow to clearly mark the typed join point 
> in the method code, instead of using combination of the method 
> annotations for the caller and callee, which have certain limitations.
> 
>  regards,
>  Eugene
> 
> 
>>> Tom Ball wrote:
>>>> Intel's comment with their vote intrigued me:  that annotations on 
>>>> blocks and loops might be useful for specifying 
>>>> atomicity/concurrency assertions.  I believe most Java programmers 
>>>> don't have a full grasp of concurrency issues, and am interested in 
>>>> any thoughts this group might have regarding concurrency assertion 
>>>> ideas and what their annotations might look like.  We can start with 
>>>> the ones in Java Concurrency in Practice, since I doubt anyone would 
>>>> argue as to their importance.
>>>>
>>>> Perhaps the best way past our logjam (uh oh, I may get spanked again 
>>>> ;-) is to come up with a conceptual set of cool assertion checkers 
>>>> whose annotations can't be placed (or can't be placed optimally), 
>>>> and then figure out how to remove those obstacles.  For me, the 
>>>> reward from working on JSRs isn't have fat specs published (and I 
>>>> doubt it is for anyone else), but their enabling of better 
>>>> technologies.  Having a new set of assertion checkers waiting to be 
>>>> written once this JSR is done is a strong motivator and focuser for me.
>>>>
>>>> Tom
>>>>
>>>
>>>
>>> _______________________________________________
>>> JSR308 mailing list
>>> JSR308 at lists.csail.mit.edu
>>> https://lists.csail.mit.edu/mailman/listinfo/jsr308
>>
> 
> 
> _______________________________________________
> JSR308 mailing list
> JSR308 at lists.csail.mit.edu
> https://lists.csail.mit.edu/mailman/listinfo/jsr308