[JSR308] Can we agree on our goals? (annotations on blocks)

[Tom Ball]

Eugene Kuleshov wrote:
> Tom Ball wrote:
>>>  Gary, why limit it on loops and not all { } blocks?
>> At the risk of polluting this discussion with implementation details, 
>> javac block nodes have an internal modifiers field, and modifiers hold 
>> annotations.  The Compiler API only allows access to the static flag 
>> in those modifiers (BlockTree.isStatic()), but that interface can be 
>> extended in a backwards-compatible way to provide access to the 
>> annotations.
>>
>> The advantage of allowing annotations on blocks rather than on 
>> statements is that developers can surround any statement with a block 
>> if they want to annotate it, without  having to make radical 
>> modifications to the compiler.  It should also make scoping issues 
>> simpler, too.  I haven't thought out what the impact of having block 
>> annotations will be on JVM classfiles, but suspect that the current 
>> proposed attribute will work.
>  Tom, does block nodes have information about type of the parent, i.e. 
> if/else/for/try/catch/etc ?

No node has any knowledge of its parents, as javac's AST is a directed 
acyclic graph.  I'm not sure parent information is useful anyway since 
loop statements don't necessarily have blocks -- they have child 
statements which may or may not be blocks.

However, I was suggesting putting a block around the statement(s) to be 
annotated:

    @DoForever {
        for (;;) {
           ...
        }
    }

No parent node knowledge is needed here, whereas it would be a serious 
compiler whack to support something like "for (;;) @DoForever { ... }". 
  IMHO, I think the former is easier to read.

Tom