[JSR308] annotations on code blocks and statements

[Eugene Kuleshov]

  Another topic for discussion is annotations on code blocks. As Michael 
Ernst pointed out there is already good deal of interest on those.

  Practical examples include JML and BML code annotations

http://www.cs.iastate.edu/~leavens/JML/
http://mobius.inria.fr/twiki/bin/view/Tools/BytecodeModelingLanguage

  I'll be refering to the current draft of the proposal as published at 
http://pag.csail.mit.edu/jsr308/java-annotation-design.pdf

  Note that specification already defines method receiver annotation 
(page 3, and tokens 6 and 7 in table on Figure 2 on page 8). Though it 
is unclear if RuntimeVisibleTypeAnnotations and 
RuntimeInvisibleTypeAnnotations should be defined as a method attributes 
or as a code attributes in the bytecode.

  Here are a few examples of expanding this idea to other code block types:

@ReadOnly { ...
}  // static code block, method body or inner code block

singeStatementOrMethodCall() @ReadOnly;

synchronized(...) @ReadOnly { ...
}

for(...) @ReadOnly { ...
}

if() @ReadOnly { ...
} else @ReadOnly { ...
}

try @ReadOnly { ...
} catch() @ReadOnly { ...
} finally @ReadOnly { ...
}

  Open question is if above syntax should use prefix or suffix form? 
I.e. variants:

@ReadOnly for(...) { ... }
for(...) @ReadOnly { ... }   // probably the most consistent one
for(...) { ... } @ReadOnly   // doesn't seem to work

  From the bytecode point of view things look less complicated. Those 
blocks already tracked by Java compiler (i.e. to identify scope of the 
local variables) and in some cases even represented in other bytecode 
attributes (i.e. try/catch ranges and debug info for the method local 
variables). So, we can similarly introduce new target_type's for 
extended_annotation (page 7) written into RuntimeVisibleTypeAnnotations 
and RuntimeInvisibleTypeAnnotations bytecode attributes. In that case 
the reference_info structure (page 8) would look like this:

{
  u2 start_pc;
  u2 end_pc;
} reference_info;

  where start_pc and end_pc indicate range in the code array where 
annotation is active (similar to the exception_table structure in the 
Code bytecode attribute.

  One last thing I'd like to mention that since this target type is 
using offsets in the code, it should be written in the attributes 
structure inside Code attribute in the bytecode. Also, due to some JVM 
specifics, it might be possible that single code block in Java language 
can be represented as several code ranges in the bytecode (i.e. 
synchonized block compilation into monitorenter/exit bytecodes and 
exception handling).

  regards,
  Eugene