[Jsr308-statements] annotations on code blocks

[Eugene Kuleshov]

Hi all,

  To base discussion on something, I am resending updated version of my 
email about annotations on code blocks that I sent earlier to the main 
JSR 308 discussion list.

  As Michael Ernst pointed out there is already good deal of interest on 
code block annotations and they been also been mentioned in the comments 
on JSR 308 review ballot.

  Practical examples include JML and BML code annotations. The are using 
specially formatted comments in the Java source code to generate 
additional metadata and store that metadata inside bytecode using 
special tools/compilers:
  http://www.cs.iastate.edu/~leavens/JML/
  http://mobius.inria.fr/twiki/bin/view/Tools/BytecodeModelingLanguage

  I have to say that my interest in this is coming from use cases 
related to the static code analysis and post-processing, primarily at 
the bytecode level.

-----
  Here are a few examples of the possible syntax. It is been suggested 
that prefix form is more readable then postfix variant. Anyways we have 
the following variants to consider:

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

  Using prefix form annotations could look like this:

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

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

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

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

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

-----
  From the bytecode point of view things look less complicated. I'll be 
refering to the current draft of the proposal as published at 
http://pag.csail.mit.edu/jsr308/

  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.

  Code blocks already tracked by Java compiler, i.e. to identify ranges 
of the try/catch blocks and even represented in bytecode attributes. By 
introducing new target_type for extended_annotation (page 7) we can 
record these code ranges for the annotation. In that case the 
reference_info structure (page 8) would look like this:

{
  u1 num_of_code_ranges;
  {
    u2 start_pc;
    u2 end_pc;
  } code_range[num_of_code_ranges]
} 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). Note that we can have multiple code ranges for 
the same annotation, and that should allow to map original source code 
block to the set of instructions in the bytecode.

  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.
-----------

  Comments, thoughts?

  regards,
  Eugene