tests for "strange behavior"

[Werner Dietl]

Steve,

thanks for these test cases! I'm waiting on a reply from Jon on my
question about this issue in:

http://mail.openjdk.java.net/pipermail/type-annotations-dev/2013-April/000777.html

Jon acknowledge the issue in his message:

http://mail.openjdk.java.net/pipermail/type-annotations-dev/2013-April/000823.html

but there was no progress since then.

Regarding T8013065.java: the copyright year is wrong.
The comment:

  33 /*
  34  * A type-annotations on a field in an inner class not in a
lambda expression
  35  * results in RuntimeTypeAnnotations_attibute and
RuntimeAnnotations_attribute.
  36  * On a field in an innner class in a lambda expression, it leaves off the
  37  * RuntimeAnnotations_attribute.
  38  */

The test seems to be about anonymous inner classes, not lambda expressions.
The error is that it leaves off a RuntimeTYPEAnnotations_Attribute.

Regarding TestAnonInnerClasses.java: I think the comma behind the
copyright is missing.
I only quickly browsed through the remainder of that test code.

Thanks,
cu, WMD.

On Tue, Apr 23, 2013 at 3:08 PM, Steve Sides <steve.sides at oracle.com> wrote:
> Hi Werner,
>  A little while ago you mention some strange behavior where type annotations
> were not being written to the classfile.
> I have a test for that, a smaller specific one and a larger one covering
> more test cases, http://cr.openjdk.java.net/~ssides/8013065/
>
> The regression test covers the basic issue that when the inner class (in
> anonymous class) is instanciated the type-annotations are written as
> annotations rather than as type annotations.
>
>     class Test<T> {
>          Object mtest( Test<T> t){ return null;  }
>         public void test() {
>             mtest( new Test<T>() {
>                     class InnerAnon<U> {
>                         @A @B String ia_m1(){ return null; };
>                     }
>                     //comment below and they're written correctly.
>                     InnerAnon<String> IA = new InnerAnon< String>();
>                });
>        }
>     }
>     @Retention(CLASS) @Target(TYPE_USE)  @interface A { }
>     @Retention(RUNTIME) @Target(TYPE_USE)  @interface B { }
>
> It's even a little stranger in that @A and @B aren't those "silly
> annotations" with type and decl targets, only TYPE_USE.
>
> The larger case coverage more test cases but the issue seems the same, too
> few type annotations and too many  annotations.
> For now, the larger case as is does not run the repeated annotation
> scenarios:
>
>   59     Boolean [][] bRepeat = new Boolean[][]{
>   60                  /* no repeats    */ {false, false, false, false,
> false, false}
>   61                  /* repeat A,C,TA */ //{true,  false, true,  false,
> true,  false}
>   62                  /* repeat B,D,TB  {false, true,  false, true,  false,
> true}, */
>   63                  /* repeat all     {true,  true,  true,  true,  true,
> true}*/
>
> only the non-repeated ones.  However, as is, it might be helpful in testing
> the fix for this.
>
> -steve



--
http://www.google.com/profiles/wdietl