From wdietl at gmail.com  Tue Feb 12 16:17:39 2013
From: wdietl at gmail.com (Werner Dietl)
Date: Tue, 12 Feb 2013 16:17:39 -0800
Subject: Annotations on anonymous classes
Message-ID: <CAJYRO=7=EaO209ua+YCGQJ9PX8J7jkN3SP5g9+RsCKmH2MOxGg@mail.gmail.com>

I have a question about anonymous classes and want to make sure we're
all on the same page on where type and declaration annotations should
go.

Let's take this code:

    interface Bound<X extends Object> {}

    void test() {
        new Bound<String>() { };
    }

This is equivalent to having:

    interface Bound<X extends Object> {}

    class Anon extends Object implements Bound<String> {}

    void test() {
        new Anon();
    }

Now, let's take a declaration annotation @DA and type annotations @TA
and @TB, and use them like this:

    interface Bound<X extends Object> {}

    void test() {
        new @DA @TA Bound<@TB String>() { };
    }

This should be translated to:

    interface Bound<X extends Object> {}

    @DA
    class Anon extends Object implements @TA Bound<@TB String> {}

    void test() {
        new @TA Anon();
    }

Note that I have @TA both on the implemented interface and on the
instantiation and @DA only on the class declaration.
Also note how @TB is not stored at the instantiation at all (this
might be surprising; if Bound were a class an instantiation "new @TA
Bound<@TB String>()" would obviously store both @TA and @TB with the
instantiation).

Is this the right way to interpret these annotations?
Should the specification explicitly state what the translation should be?

Thanks,
cu, WMD.

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

From roman.shevchenko at jetbrains.com  Thu Feb 14 05:05:55 2013
From: roman.shevchenko at jetbrains.com (Roman Shevchenko)
Date: Thu, 14 Feb 2013 14:05:55 +0100
Subject: specification example: receiver in inner constructor
Message-ID: <op.wshyn5fnrj4h8l@munit-012.labs.intellij.net>

Hi!

I wonder if this example of a receiver annotation is correct:

   class Outer {
     class Inner {
       @Result Inner(@Receiver Outer Outer.this, boolean b) { }
     }
   }

It has receiver have a type Outer instead of Inner, and a syntax  
'Outer.this' isn't understood by  
1.8.0-ea-jsr308-nightly-h2410-20121221-b69-b00 compiler.

(I'm referring to the spec from January 30, 2013 at  
http://types.cs.washington.edu/jsr308/specification/java-annotation-design.html)

Thanks.

From ebruneton at free.fr  Sun Feb 17 02:22:57 2013
From: ebruneton at free.fr (Eric Bruneton)
Date: Sun, 17 Feb 2013 11:22:57 +0100
Subject: some errors in the specification (january 30 version)
Message-ID: <5120AF81.6050102@free.fr>

FYI, I updated the type annotation implementation in the ASM branch 
ASM_5_FUTURE, to match the latest version of the JSR. I hope it is 
correct, but I have no reference implementation against which to test it 
(is there one)?

By doing this, I noticed two small bugs in the specification:
- the first sentence in 3.3.10 references 
invocation_type_argument_target and method_reference_type_argument, 
which are not defined.
- in 3.4, in the type_path_entry struct definition, the 
type_argument_index comment is inconsistent with the sentence just below 
"When type_path_kind is 0, 1, or 2, then type_argument_index must be 0" 
(0 is valid for a type_path_kind 3, and designates the 1st type arg).

Finally I'm wondering, in 3.3.10, how the value of type_argument_index 
is defined for a castinstruction.

Eric

From wdietl at gmail.com  Sun Feb 17 20:56:23 2013
From: wdietl at gmail.com (Werner Dietl)
Date: Sun, 17 Feb 2013 20:56:23 -0800
Subject: [type-annos-observers] some errors in the specification (january
	30 version)
In-Reply-To: <5120AF81.6050102@free.fr>
References: <5120AF81.6050102@free.fr>
Message-ID: <CAJYRO=5WTKV2Q2Qbd4wLRhcHcy9V5WTfFCRn_wtWpMz=VK_+8Q@mail.gmail.com>

Hi Eric,

thanks for the update!

On Sun, Feb 17, 2013 at 2:22 AM, Eric Bruneton <ebruneton at free.fr> wrote:
> FYI, I updated the type annotation implementation in the ASM branch
> ASM_5_FUTURE, to match the latest version of the JSR. I hope it is correct,
> but I have no reference implementation against which to test it (is there
> one)?

The reference implementation for JSR 308 is available here:

http://openjdk.java.net/projects/type-annotations/

It has also been recently integrated into the main TL branch and
should be included in JDK 8 binary builds.

You could compile a source program with this javac and then see
whether ASM presents the results correctly.
You could insert type annotations using ASM and then see whether this
javap presents the results correctly.

Please do let me know if you see any problem with the reference implementation.
cu, WMD.


> By doing this, I noticed two small bugs in the specification:
> - the first sentence in 3.3.10 references invocation_type_argument_target
> and method_reference_type_argument, which are not defined.
> - in 3.4, in the type_path_entry struct definition, the type_argument_index
> comment is inconsistent with the sentence just below "When type_path_kind is
> 0, 1, or 2, then type_argument_index must be 0" (0 is valid for a
> type_path_kind 3, and designates the 1st type arg).
>
> Finally I'm wondering, in 3.3.10, how the value of type_argument_index is
> defined for a castinstruction.
>
> Eric



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

From wdietl at gmail.com  Mon Feb 18 01:03:26 2013
From: wdietl at gmail.com (Werner Dietl)
Date: Mon, 18 Feb 2013 01:03:26 -0800
Subject: Storing declaration annotations on a local variable
Message-ID: <CAJYRO=5r7J0=nZsm+mSZhoXNhWrpNp0CF=dwcsrFxVJHpOnWSQ@mail.gmail.com>

Java 1.5 declaration annotations on local variables can be written,
but are not stored in the bytecode.
Java 1.8 type annotations on a local variable are stored in the bytecode.
Should we store declaration annotations on local variables together
with type annotations on local variables?

Let's assume a declaration annotation @DA, a type annotation @TA, and this code:

class Test {
    @TA @DA Object f = null;

    void foo() {
	@TA @DA Object l = null;
    }
}

A fragment of the output of javap -v is:

  java.lang.Object f;
    descriptor: Ljava/lang/Object;
    flags:
    RuntimeInvisibleAnnotations:
      0: #8()
    RuntimeInvisibleTypeAnnotations:
      0: #10(): FIELD
  ...
  void foo();
    descriptor: ()V
    ...
    RuntimeInvisibleTypeAnnotations:
      0: #10(): LOCAL_VARIABLE, {start_pc=2, length=1, index=1}

(Where #8 is @DA and #10 is @TA.)
That is, as expected, the field has both the declaration and the type
annotation, whereas the local variable only stores the type
annotation.

Storing declaration annotations for local variables will enable more
use cases for declaration annotations and make the language more
consistent.

It should be very simple to store the declaration annotation together
with the type annotation, giving something like:

    RuntimeInvisibleTypeAnnotations:
      0: #8(): LOCAL_VARIABLE, {start_pc=2, length=1, index=1}
      1: #10(): LOCAL_VARIABLE, {start_pc=2, length=1, index=1}

The obvious disadvantage being that we would now mix type and
declaration annotations. Instead, with a bit more work, we could
introduce a RuntimeInvisibleLocalVariableAnnotation that is used just
for this purpose. It would use the same format as for type annotations
on local variables and should be straightforward to implement.

The reflection API will not be extended to expose these declaration
annotations on local variables.

What do you think of this proposal?
cu, WMD.

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

From joe.darcy at oracle.com  Fri Feb 15 17:06:51 2013
From: joe.darcy at oracle.com (Joseph Darcy)
Date: Fri, 15 Feb 2013 17:06:51 -0800
Subject: Comments on preliminary javax.lang.model changes for JSR 308
Message-ID: <511EDBAB.2090402@oracle.com>

Greetings JSR 308 experts,

The initial push of the JSR 308 changes into JDK 8 [1], included various 
changes to the javax.lang.model API

1) New type javax.lang.model.type.AnnotatedType
2) New method ExecutableType.getReceiverType
3) New enum constant TypeKind.ANNOTATED
4) New method on visitor interface TypeVisitor.visitAnnotated
5) Update of AbstractTypeVisitor6 with an implementation of visitAnnotated.
6) Several new methods in javax.lang.model.util.Types

Given the direction being taken for javax.lang.model support for type 
annotations [2], with the possible exception of 2) and some of 6), the 
rest of these changes should be reverted.  The the proposed design in 
[2], all types are potentially annotated so classifying types in the API 
as annotated or not is not a helpful distinction.

Thanks,

-Joe
JSR 269 Maintenance Lead

[1] 8006775: JSR 308: Compiler changes in JDK8,
http://hg.openjdk.java.net/jdk8/tl/langtools/rev/71f35e4b93a5

[2] 
http://mail.openjdk.java.net/pipermail/type-annotations-spec-experts/2013-February/000064.html

From joe.darcy at oracle.com  Sun Feb 17 12:48:44 2013
From: joe.darcy at oracle.com (Joe Darcy)
Date: Sun, 17 Feb 2013 12:48:44 -0800
Subject: Comments on preliminary javax.lang.model changes for JSR 308
In-Reply-To: <511EDBAB.2090402@oracle.com>
References: <511EDBAB.2090402@oracle.com>
Message-ID: <5121422C.5050903@oracle.com>

PS To summarize this feedback, whether or not a type is annotated should 
be a "has-a" rather than "is-a" relationship.

Cheers,

-Joe

On 2/15/2013 5:06 PM, Joseph Darcy wrote:
> Greetings JSR 308 experts,
>
> The initial push of the JSR 308 changes into JDK 8 [1], included 
> various changes to the javax.lang.model API
>
> 1) New type javax.lang.model.type.AnnotatedType
> 2) New method ExecutableType.getReceiverType
> 3) New enum constant TypeKind.ANNOTATED
> 4) New method on visitor interface TypeVisitor.visitAnnotated
> 5) Update of AbstractTypeVisitor6 with an implementation of 
> visitAnnotated.
> 6) Several new methods in javax.lang.model.util.Types
>
> Given the direction being taken for javax.lang.model support for type 
> annotations [2], with the possible exception of 2) and some of 6), the 
> rest of these changes should be reverted.  The the proposed design in 
> [2], all types are potentially annotated so classifying types in the 
> API as annotated or not is not a helpful distinction.
>
> Thanks,
>
> -Joe
> JSR 269 Maintenance Lead
>
> [1] 8006775: JSR 308: Compiler changes in JDK8,
> http://hg.openjdk.java.net/jdk8/tl/langtools/rev/71f35e4b93a5
>
> [2] 
> http://mail.openjdk.java.net/pipermail/type-annotations-spec-experts/2013-February/000064.html


From ebruneton at free.fr  Sun Feb 24 08:18:45 2013
From: ebruneton at free.fr (Eric Bruneton)
Date: Sun, 24 Feb 2013 17:18:45 +0100
Subject: [type-annos-observers] some errors in the specification (january
	30 version)
In-Reply-To: <CAJYRO=5WTKV2Q2Qbd4wLRhcHcy9V5WTfFCRn_wtWpMz=VK_+8Q@mail.gmail.com>
References: <5120AF81.6050102@free.fr>
	<CAJYRO=5WTKV2Q2Qbd4wLRhcHcy9V5WTfFCRn_wtWpMz=VK_+8Q@mail.gmail.com>
Message-ID: <512A3D65.2060102@free.fr>

18/02/2013 05:56, Werner Dietl wrote:
> Hi Eric,
>
> thanks for the update!
>
> On Sun, Feb 17, 2013 at 2:22 AM, Eric Bruneton <ebruneton at free.fr> wrote:
>> FYI, I updated the type annotation implementation in the ASM branch
>> ASM_5_FUTURE, to match the latest version of the JSR. I hope it is correct,
>> but I have no reference implementation against which to test it (is there
>> one)?
>
> The reference implementation for JSR 308 is available here:
>
> http://openjdk.java.net/projects/type-annotations/
>
> It has also been recently integrated into the main TL branch and
> should be included in JDK 8 binary builds.
>
> You could compile a source program with this javac and then see
> whether ASM presents the results correctly.
> You could insert type annotations using ASM and then see whether this
> javap presents the results correctly.
>
> Please do let me know if you see any problem with the reference implementation.
> cu, WMD.

Thanks for the instructions. I downloaded the checkers framework v1.6.0, 
compiled the InterningExample.java example, and tried to read the 
resulting .class (attached) with ASM. I got an error and it seems this 
is because the annotations on the local variables are stored in a 
RuntimeVisibleTypeAnnotations attribute of the method, instead of being 
stored in a RuntimeVisibleTypeAnnotations attribute of the method's Code 
attribute (cf "Changes in JSR 308" in 
http://types.cs.washington.edu/jsr308/specification/java-annotation-design.html#class-file: 
"A type annotation is stored in a Runtime[In]visibleTypeAnnotations 
attribute on the smallest enclosing class, field, method, or Code 
structure."). Maybe I'm not using the correct version of the reference 
implementation?

Otherwise, if I remove these code annotations, and just use annotations 
on classes and methods, like

public class InterningExample<@Interned T extends ArrayList<@Interned 
?>> extends @Interned ArrayList implements @Interned Cloneable {
   public void example(@Interned String @Interned [] @Interned [] f) {
     String foo = "foo";
     String bar = "bar";
     if (foo == bar)
         System.out.println("foo == bar");

   }
   public @Interned int m(@Interned T e) {
	  return 0;
   }
}

Then I am able to read the corresponding class file with ASM (but I 
haven't tried to do read/write round trip test yet).

Eric


From wdietl at gmail.com  Sun Feb 24 18:17:13 2013
From: wdietl at gmail.com (Werner Dietl)
Date: Sun, 24 Feb 2013 18:17:13 -0800
Subject: [type-annos-observers] some errors in the specification (january
	30 version)
In-Reply-To: <512A3D65.2060102@free.fr>
References: <5120AF81.6050102@free.fr>
	<CAJYRO=5WTKV2Q2Qbd4wLRhcHcy9V5WTfFCRn_wtWpMz=VK_+8Q@mail.gmail.com>
	<512A3D65.2060102@free.fr>
Message-ID: <CAJYRO=5H2PWhpMazV6qyV_vyK8f8XGT+aqK9vXpZKTs+__UzhA@mail.gmail.com>

Hi Eric,

thanks for noticing that the RI stores the
RuntimeVisibleTypeAnnotations in the Method instead of a Code
attribute.
I will discuss how to verify and fix this on the type-annotations-dev
mailing list.

Also, instead of using the Checker Framework, it might be easier to
use langtools from:

http://hg.openjdk.java.net/type-annotations/type-annotations/langtools

This is where I push fixes first and only propagate to
jsr308-langtools/checker-framework when all tests work and there was
significant change.

Thanks and please keep your comments coming!
cu, WMD.


On Sun, Feb 24, 2013 at 8:18 AM, Eric Bruneton <ebruneton at free.fr> wrote:
> 18/02/2013 05:56, Werner Dietl wrote:
>>
>> Hi Eric,
>>
>> thanks for the update!
>>
>> On Sun, Feb 17, 2013 at 2:22 AM, Eric Bruneton <ebruneton at free.fr> wrote:
>>>
>>> FYI, I updated the type annotation implementation in the ASM branch
>>> ASM_5_FUTURE, to match the latest version of the JSR. I hope it is
>>> correct,
>>> but I have no reference implementation against which to test it (is there
>>> one)?
>>
>>
>> The reference implementation for JSR 308 is available here:
>>
>> http://openjdk.java.net/projects/type-annotations/
>>
>> It has also been recently integrated into the main TL branch and
>> should be included in JDK 8 binary builds.
>>
>> You could compile a source program with this javac and then see
>> whether ASM presents the results correctly.
>> You could insert type annotations using ASM and then see whether this
>> javap presents the results correctly.
>>
>> Please do let me know if you see any problem with the reference
>> implementation.
>> cu, WMD.
>
>
> Thanks for the instructions. I downloaded the checkers framework v1.6.0,
> compiled the InterningExample.java example, and tried to read the resulting
> .class (attached) with ASM. I got an error and it seems this is because the
> annotations on the local variables are stored in a
> RuntimeVisibleTypeAnnotations attribute of the method, instead of being
> stored in a RuntimeVisibleTypeAnnotations attribute of the method's Code
> attribute (cf "Changes in JSR 308" in
> http://types.cs.washington.edu/jsr308/specification/java-annotation-design.html#class-file:
> "A type annotation is stored in a Runtime[In]visibleTypeAnnotations
> attribute on the smallest enclosing class, field, method, or Code
> structure."). Maybe I'm not using the correct version of the reference
> implementation?
>
> Otherwise, if I remove these code annotations, and just use annotations on
> classes and methods, like
>
> public class InterningExample<@Interned T extends ArrayList<@Interned ?>>
> extends @Interned ArrayList implements @Interned Cloneable {
>   public void example(@Interned String @Interned [] @Interned [] f) {
>     String foo = "foo";
>     String bar = "bar";
>     if (foo == bar)
>         System.out.println("foo == bar");
>
>   }
>   public @Interned int m(@Interned T e) {
>           return 0;
>   }
> }
>
> Then I am able to read the corresponding class file with ASM (but I haven't
> tried to do read/write round trip test yet).
>
> Eric
>



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