JSR 308 and implicit n-ary lambdas

[Werner Dietl]

Lambda experts,

the parser in file
langtools/src/share/classes/com/sun/tools/javac/parser/JavacParser.java
around line 968 contains the following:

        case LPAREN:
            if (typeArgs == null && (mode & EXPR) != 0) {
                if (peekToken(MONKEYS_AT) ||
                        peekToken(FINAL) ||
                        peekToken(RPAREN) ||
                        peekToken(IDENTIFIER, COMMA) ||
                        peekToken(IDENTIFIER, RPAREN, ARROW)) {
                    //implicit n-ary lambda
                    t = lambdaExpressionOrStatement(true,
peekToken(MONKEYS_AT) || peekToken(FINAL), pos);
                    break;
                } else {

this breaks in combination with type annotations on type casts.

For an example failure, see this test case:

http://buffalo.cs.washington.edu:8080/job/type-annotations-langtools/61/testReport/com.sun.tools.javac.annotations.typeAnnotations.classfile/TypeCasts/tools_javac_annotations_typeAnnotations_classfile_TypeCasts_java/

In the above code, is the MONKEYS_AT used with the assumption that any
annotation after a LPAREN must be a declaration annotation on a parameter
and therefore a lambda should start?

In the following code:

String a0 = (@A String) o;

instead of looking for just the MONKEYS_AT, I think we will have to parse a
whole type and then see whether we hit an identifier (it's a lambda) or a
closing RPAREN (it's an annotated cast).

Do you see a simpler way to disambiguate this? Am I misunderstanding what's
happening here?

Thanks,
cu, WMD.

-- 
http://www.google.com/profiles/wdietl
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/type-annotations-dev/attachments/20121108/16f1b266/attachment.html