[Jsr308-statements] JSR-308 Statements document update (discussion items and grammar changes)

[Eugene Kuleshov]

  I think there are several discussion items that need to be clarified:

-- Alternatives for the new java syntax for annotations on statements 
and code blocks.
  Trevor's prototype introduced annotation for loop AST nodes, but as 
both Neal and Michael pointed out while back it is not generic enough 
and we need to look trough the entire Java language grammar [1]. Here is 
my attempt to identify all places we should add statement/block 
annotations to.

  Option 1.

Block:
        [Annotations] { BlockStatements }

Statement:
        Block
        assert Expression [ : Expression] ;
     [Annotations] if ParExpression Statement [[Annotations] else Statement]
     [Annotations] for ( ForControl ) Statement
     [Annotations] while ParExpression Statement
     [Annotations] do Statement [Annotations] while ParExpression   ;
     [Annotations] try Block ( Catches | [Catches] finally Block )
     [Annotations] switch ParExpression { SwitchBlockStatementGroups }
     [Annotations] synchronized ParExpression Block
     [Annotations] return [Expression] ;
     [Annotations] throw Expression   ;
     [Annotations] break [Identifier]
     [Annotations] continue [Identifier]
        ;
        [Annotations] StatementExpression ;
        Identifier   : Statement

Catches:
        CatchClause {CatchClause}

CatchClause:
     [Annotations] catch ( FormalParameter ) Block

  In this case we could also introduce additional annotation targets and 
expand java.lang.annotation.ElementType [2] enum for new placeholders 
(i.e. block, if, else, for, etc...).

  I have mixed feelings about this approach because it don't support 
some use cases too well. For instance, example shown in the 
"concurrency" section [5] require to identify code block in the bytecode 
for the annotated Java code block. The following syntax look nicer

@Lock(type=LockType.Optimistic) synchronized(mutex) {
  ...
}

  but it is also possible to write it like this (above grammar allows it):

synchronized(mutex) @Lock(type=LockType.Optimistic) {
  ...
}

  Those need to be aligned to the suggested compilation in JVM spec [6].


  Option 2.

  Alternative approach could be to only allow annotations on code 
blocks. Then grammar change would be much smaller:

Block:
        [Annotations] { BlockStatements }

  That would still allow to annotate loops but syntax would look 
something like this:

  for(Item i : items)
  @LoopBound(max=100) {
     ...
  }

  That should not affect analysis at the bytecode level but may make 
source-level analysis more complicated because it will have to track the 
parent nodes or rely on specific annotation types. In this case we'll 
need only one addition to the java.lang.annotation.ElementType enum 
(i.e. CODE_BLOCK)

---------------------

  In section "New Class File Attributes" [3], we need to decide if we 
should use separate Runtime*StatementAnnotations or can reuse common 
Runtime*TypeAnnotations attribute described in the main jsr308 spec [4] 
and use special target_type value for statement/block annotations.

  In section "Block Syntax Support", we may need to consider using array 
of reference_info to mark ranges of the code block in case if it is 
split into the several ranges in the bytecode (i.e. "finally" and 
probably some other cases).

  It is also topic for discussion if regular non-block statements should 
be represented as a code range and not just an offset in the bytecode. 
The reason is to make it easier to identify code for given statement. 
For example, Java fragment like:

  return a + b;

  is represented in the bytecode as

    NEW StringBuilder
    DUP
    ALOAD 1: a
    INVOKESTATIC String.valueOf(Object) : String
    INVOKESPECIAL StringBuilder.<init>(String) : void
    ALOAD 2: b
    INVOKEVIRTUAL StringBuilder.append(String) : StringBuilder
    INVOKEVIRTUAL StringBuilder.toString() : String
    ARETURN

  Support for this in the Java compiler will be of course more 
complicated then just adding a starting offset for this code block 
(unless we'll choose to go with above Option 2, then ).

  regards,
  Eugene

[1] http://docs.oracle.com/javase/specs/jls/se5.0/html/syntax.html#18.1
[2] 
http://java.sun.com/j2se/1.5.0/docs/api/java/lang/annotation/ElementType.html
[3] 
http://doc.ece.uci.edu/mediawiki/index.php/JSR-308_Statements#New_Class_File_Attributes
[4] http://pag.csail.mit.edu/jsr308/java-annotation-design.html#htoc8
[5] 
http://doc.ece.uci.edu/mediawiki/index.php/JSR-308_Statements#Concurrency.2C_Atomicity.2C_and_Parallelization
[6] 
http://docs.oracle.com/javase/specs/jvms/se5.0/html/Compiling.doc.html#6530


Trevor Harmon wrote:
> I've made some changes to the JSR-308 Statements document [1] based on 
> advice from Michael Ernst. Looks like Eugene Kuleshov has also been 
> adding content; thanks! So the document is a bit more polished now, 
> although there are still a couple of to-do items, as listed on the 
> article's discussion page.
>
> If you have more ideas for the document, please post them to this 
> list, add them to the discussion page, or simply edit the article 
> itself! (It's a wiki, after all.)
>
> Trevor
>
> [1] http://doc.ece.uci.edu/mediawiki/index.php/JSR-308_Statements
>
>
> _______________________________________________
> JSR308-statements mailing list
> JSR308-statements at lists.csail.mit.edu
> https://lists.csail.mit.edu/mailman/listinfo/jsr308-statements