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: [type-annos-observers] 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 alex.buckley at oracle.com  Tue Feb 12 17:43:46 2013
From: alex.buckley at oracle.com (Alex Buckley)
Date: Tue, 12 Feb 2013 17:43:46 -0800
Subject: [type-annos-observers] Annotations on anonymous classes
In-Reply-To: <CAJYRO=7=EaO209ua+YCGQJ9PX8J7jkN3SP5g9+RsCKmH2MOxGg@mail.gmail.com>
References: <CAJYRO=7=EaO209ua+YCGQJ9PX8J7jkN3SP5g9+RsCKmH2MOxGg@mail.gmail.com>
Message-ID: <511AEFD2.2030506@oracle.com>

Hi Werner,

Thanks for writing to the -spec-comments list.

On 2/12/2013 4:17 PM, Werner Dietl wrote:
> 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();
>      }

The JSR 308 spec has a problem: the 'Creator' production in JLS ch.18 
does not use 'Type', so it is unaffected by JSR 308's addition of 
'Annotations' to 'Type'. In other words, no annotations after 'new' are 
permitted by the spec! Obviously they should be, if their type has TYPE 
or TYPE_USE in @Target.

> Note that I have @TA both on the implemented interface and on the
> instantiation and @DA only on the class declaration.

The JSR 308 should say how these annotations are distributed over Anon, 
since Anon's existence and form are specified by JLS 15.9.1, 15.9.5, and 
13.1.

The application of @DA to the class declaration looks good.

The application of @TA to the type mentioned in the anonymous class 
declaration also looks good. No need to sprinkle @TA over Object.

I assume that if Bound was a class, then 'new @TA Bound<..>() { }' would 
cause @TA to appear on the superclass.

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

My answer here is that @TA should not be left in 'new @TA Anon()'. An 
anonymous class declaration within a class instance creation expression 
has a unique binary name. Therefore, tools which seek annotations on a 
class instance creation expression can easily recognize that "an 
anonymous class was instantiated here", and find the corresponding class 
declaration with potential type-decl _and_ type-use annotations.

I suspect moving _all_ type-decl and type-use annotations to the 
implicitly-declared Anon class is simpler to implement too, versus 
leaving some of them back at the creation expression.

Alex

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: [type-annos-observers] 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 alex.buckley at oracle.com  Fri Feb 15 12:51:40 2013
From: alex.buckley at oracle.com (Alex Buckley)
Date: Fri, 15 Feb 2013 12:51:40 -0800
Subject: [type-annos-observers] Type Annotations in the language model API
Message-ID: <511E9FDC.1030101@oracle.com>

Experts,

Previously [1], we proposed to represent type annotations in the 
language model API via an AnnotatedTypeMirror hierarchy that parallels 
the TypeMirror hierarchy. This proposal was driven by an abundance of 
caution for language model implementations that share TypeMirror objects 
across different use sites, such as a single TypeMirror object for both 
uses of String in "@Foo String f1; @Bar String f2;". In addition, we 
proposed new methods on {Type,Variable,Executable}Element to expose 
AnnotatedTypeMirror objects.

We now think our proposal was excessively concerned about freedom for 
implementers of the language model API, rather than keeping a simple 
conceptual model for users of the API.

In keeping with how the Java language now supports annotations on both 
declarations and type uses, we propose to expose annotations uniformly 
on javax.lang.model.element.Element (declarations) and 
javax.lang.model.type.TypeMirror (type uses).

To this end, we propose to pull the annotation methods of Element into a 
new interface which is implemented by both Element and TypeMirror:

package javax.lang.model;
interface AnnotatedConstruct {
   <A extends Annotation> A         getAnnotation(Class<A>);
   <A extends Annotation> A[]       getAnnotationsByType(Class<A>)
   List<? extends AnnotationMirror> getAnnotationMirrors();
}

(getAnnotationsByType is a new method for repeating annotations, 
discussed on the enhanced-metadata-spec-discuss list.)

The implication for implementers is that a TypeMirror object cannot 
_always_ be shared across multiple uses of a type in 
class/interface/field/method/ctor declarations. Previously, a TypeMirror 
object could _always_ be shared in this manner.

For example, suppose v1 is the VariableElement for the field "@Foo 
String f1;" and v2 is the VariableElement for the field "@Bar String 
f2;". In Java SE 8, v1.asType() must not return the same TypeMirror 
object as v2.asType(). But suppose v3 is the VariableElement for "@Quux 
String f3;" and v4 is the VariableElement for "@Quux String f4;". 
v3.AsType() may return the same TypeMirror object as v4.asType().

Essentially, the concept which TypeMirror has always represented - "type 
in the Java programming language" - is now expanded to "potentially 
annotated type in the Java programming language".

For compatibility, the utility methods for type comparison in 
javax.lang.model.util.Types should ignore annotations. New methods can 
be added, but comparing annotations may be a rathole, so please let's 
use a new thread for utility methods.

We don't propose to revisit type annotations in the core reflection API. 
There, we need new methods exposing a new AnnotatedType hierarchy 
because the legacy Type hierarchy is truly limited to declarations, both 
in concept and in implementation.

Alex

[1] 
http://mail.openjdk.java.net/pipermail/type-annotations-spec-experts/2012-September/000001.html

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: [type-annos-observers] 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: [type-annos-observers] 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 srikanth_sankaran at in.ibm.com  Mon Feb 18 04:59:20 2013
From: srikanth_sankaran at in.ibm.com (Srikanth S Adayapalam)
Date: Mon, 18 Feb 2013 07:59:20 -0500
Subject: [type-annos-observers] Spec refresh at JCP site ?
In-Reply-To: <OF311F1254.9A87D3F8-ON65257A8B.000F1F4A-65257A8B.000FFA4F@LocalDomain>
References: <50516CF6.6050400@free.fr>
	<20120921.031537.857440125198746700.mernst@cs.washington.edu>
	<OF311F1254.9A87D3F8-ON65257A8B.000F1F4A-65257A8B.000FFA4F@LocalDomain>
Message-ID: <OF2CF88C51.6FF98CB3-ON65257B16.0045FAC6-85257B16.00811DE6@in.ibm.com>

Hello !

Is it known when we can expect the next refresh at the JCP site. I know
very recent versions are available at the University site, but the 
question
is specifically about JCP site.

TIA,
Srikanth

From alex.buckley at oracle.com  Mon Feb 18 10:41:21 2013
From: alex.buckley at oracle.com (Alex Buckley)
Date: Mon, 18 Feb 2013 10:41:21 -0800
Subject: [type-annos-observers] Spec refresh at JCP site ?
In-Reply-To: <OF2CF88C51.6FF98CB3-ON65257B16.0045FAC6-85257B16.00811DE6@in.ibm.com>
References: <50516CF6.6050400@free.fr>
	<20120921.031537.857440125198746700.mernst@cs.washington.edu>
	<OF311F1254.9A87D3F8-ON65257A8B.000F1F4A-65257A8B.000FFA4F@LocalDomain>
	<OF2CF88C51.6FF98CB3-ON65257B16.0045FAC6-85257B16.00811DE6@in.ibm.com>
Message-ID: <512275D1.8000103@oracle.com>

Mike and I were not planning another Early Draft Review. We were 
planning for the next milestone to be a Public Review aligned with the 
Public Reviews of other SE 8 JSRs. I have no information of any kind 
about when those Public Reviews would happen.

Alex

On 2/18/2013 4:59 AM, Srikanth S Adayapalam wrote:
> Hello !
>
> Is it known when we can expect the next refresh at the JCP site. I know
> very recent versions are available at the University site, but the
> question
> is specifically about JCP site.
>
> TIA,
> Srikanth
>

From alex.buckley at oracle.com  Mon Feb 18 11:16:53 2013
From: alex.buckley at oracle.com (Alex Buckley)
Date: Mon, 18 Feb 2013 11:16:53 -0800
Subject: [type-annos-observers] Comments on preliminary javax.lang.model
	changes for JSR 308
In-Reply-To: <511EDBAB.2090402@oracle.com>
References: <511EDBAB.2090402@oracle.com>
Message-ID: <51227E25.90106@oracle.com>

Thanks for raising this issue. The language model API changes should 
indeed be limited to solely the AnnotatedConstruct methods I outlined at 
[2], plus the getReceiverType() and Types methods you identify. Let's 
discuss those in the thread at [2].

Alex

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 alex.buckley at oracle.com  Mon Feb 18 13:03:05 2013
From: alex.buckley at oracle.com (Alex Buckley)
Date: Mon, 18 Feb 2013 13:03:05 -0800
Subject: [type-annos-observers] Type Annotations in the language model
	API
In-Reply-To: <511E9FDC.1030101@oracle.com>
References: <511E9FDC.1030101@oracle.com>
Message-ID: <51229709.3080606@oracle.com>

As raised by Joe Darcy elsewhere, the language model needs to consider 
the only truly new construct in the language for type annotations: the 
'this' pseudo-parameter which allows annotations on the type of the 
object on which a method/ctor is invoked.

The question is whether to expose a mirror for that type via:

i) a new method ExecutableElement.getReceiverType() that returns a 
TypeMirror, or

ii) inserting a VariableElement for 'this' into the result of 
Executable.getParameters(), from which clients can get a TypeMirror via 
asType().

I favor (i) for three reasons:

- The EG agreed previously that a method parameter named 'this' is not 
truly a formal parameter declaration. It isn't reified in a method 
descriptor, and it's best not to let it be annotated by a 
PARAMETER-targeting annotation. Therefore it doesn't deserve a 
VariableElement.

- getReceiverType() is easy to implement in ExecutableElement because 
the result can always be based on the result of asType() from the 
enclosing TypeElement. Just sprinkle in the type annotations from a 
'this' pseudo-parameter if available from source.

- getReceiverType() loosely follows 
j.l.r.Method.getAnnotatedReceiverType(). 
(ExecutableElement.getAnnotatedReceiverType() would not be a good name 
because in the language model, we've pushed annotations into type 
mirrors per Joe's "has-a" comment.)

Alex

On 2/15/2013 12:51 PM, Alex Buckley wrote:
> Experts,
>
> Previously [1], we proposed to represent type annotations in the
> language model API via an AnnotatedTypeMirror hierarchy that parallels
> the TypeMirror hierarchy. This proposal was driven by an abundance of
> caution for language model implementations that share TypeMirror objects
> across different use sites, such as a single TypeMirror object for both
> uses of String in "@Foo String f1; @Bar String f2;". In addition, we
> proposed new methods on {Type,Variable,Executable}Element to expose
> AnnotatedTypeMirror objects.
>
> We now think our proposal was excessively concerned about freedom for
> implementers of the language model API, rather than keeping a simple
> conceptual model for users of the API.
>
> In keeping with how the Java language now supports annotations on both
> declarations and type uses, we propose to expose annotations uniformly
> on javax.lang.model.element.Element (declarations) and
> javax.lang.model.type.TypeMirror (type uses).
>
> To this end, we propose to pull the annotation methods of Element into a
> new interface which is implemented by both Element and TypeMirror:
>
> package javax.lang.model;
> interface AnnotatedConstruct {
>    <A extends Annotation> A         getAnnotation(Class<A>);
>    <A extends Annotation> A[]       getAnnotationsByType(Class<A>)
>    List<? extends AnnotationMirror> getAnnotationMirrors();
> }
>
> (getAnnotationsByType is a new method for repeating annotations,
> discussed on the enhanced-metadata-spec-discuss list.)
>
> The implication for implementers is that a TypeMirror object cannot
> _always_ be shared across multiple uses of a type in
> class/interface/field/method/ctor declarations. Previously, a TypeMirror
> object could _always_ be shared in this manner.
>
> For example, suppose v1 is the VariableElement for the field "@Foo
> String f1;" and v2 is the VariableElement for the field "@Bar String
> f2;". In Java SE 8, v1.asType() must not return the same TypeMirror
> object as v2.asType(). But suppose v3 is the VariableElement for "@Quux
> String f3;" and v4 is the VariableElement for "@Quux String f4;".
> v3.AsType() may return the same TypeMirror object as v4.asType().
>
> Essentially, the concept which TypeMirror has always represented - "type
> in the Java programming language" - is now expanded to "potentially
> annotated type in the Java programming language".
>
> For compatibility, the utility methods for type comparison in
> javax.lang.model.util.Types should ignore annotations. New methods can
> be added, but comparing annotations may be a rathole, so please let's
> use a new thread for utility methods.
>
> We don't propose to revisit type annotations in the core reflection API.
> There, we need new methods exposing a new AnnotatedType hierarchy
> because the legacy Type hierarchy is truly limited to declarations, both
> in concept and in implementation.
>
> Alex
>
> [1]
> http://mail.openjdk.java.net/pipermail/type-annotations-spec-experts/2012-September/000001.html
>

From alex.buckley at oracle.com  Tue Feb 19 16:19:24 2013
From: alex.buckley at oracle.com (Alex Buckley)
Date: Tue, 19 Feb 2013 16:19:24 -0800
Subject: [type-annos-observers] Type Annotations in the language model
	API
In-Reply-To: <51229709.3080606@oracle.com>
References: <511E9FDC.1030101@oracle.com> <51229709.3080606@oracle.com>
Message-ID: <5124168C.3090902@oracle.com>

On 2/18/2013 1:03 PM, Alex Buckley wrote:
> As raised by Joe Darcy elsewhere, the language model needs to consider
> the only truly new construct in the language for type annotations: the
> 'this' pseudo-parameter which allows annotations on the type of the
> object on which a method/ctor is invoked.
>
> The question is whether to expose a mirror for that type via:
>
> i) a new method ExecutableElement.getReceiverType() that returns a
> TypeMirror, or

We are working on adding this method.

It will return a TypeMirror which is a DeclaredType if the 
ExecutableElement represents an instance method or an inner constructor.

It will return a TypeMirror which is a NoType (kind NONE) if the 
ExecutableElement represents a static method or an initializer (static 
or instance).

We also plan to add ExecutableType.getReceiverType(), since 
ExecutableType generally follows ExecutableElement in exposing 
sub-structural types, e.g. return type.

It will return a TypeMirror which is a DeclaredType if the 
ExecutableType represents the type of an executable which is an instance 
method or an inner constructor.

It will return a TypeMirror which is a a NoType (kind NONE) if the 
ExecutableType represents the type of an executable which is a static 
method or an initializer (static or instance).

Alex

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

From alex.buckley at oracle.com  Mon Feb 25 10:39:20 2013
From: alex.buckley at oracle.com (Alex Buckley)
Date: Mon, 25 Feb 2013 10:39:20 -0800
Subject: [type-annos-observers] Missing location of
	Runtime[In]VisibleTypeAnnotations attribute
Message-ID: <512BAFD8.3030105@oracle.com>

Section 3 of the spec says: "A type annotation is stored in a 
Runtime[In]visibleTypeAnnotations attribute on the smallest enclosing 
class, field, method, or Code structure."

Subsections then give the exact storage location for most, but not all, 
of the possible type annotations. The location is missing in 3.3.9 "Type 
tests, object creation, and method/constructor references" - an omission 
which partly led to dropped annotations in the RI [1]. Also, 3.3.10 
gives a location but is inconsistent about the name of the structure 
being stored.

Alex

[1] 
http://mail.openjdk.java.net/pipermail/type-annotations-dev/2013-February/000629.html

From joe.darcy at oracle.com  Mon Feb 18 09:53:58 2013
From: joe.darcy at oracle.com (Joe Darcy)
Date: Mon, 18 Feb 2013 17:53:58 -0000
Subject: [type-annos-observers] 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 joe.darcy at oracle.com  Mon Feb 18 09:53:58 2013
From: joe.darcy at oracle.com (Joseph Darcy)
Date: Mon, 18 Feb 2013 17:53:58 -0000
Subject: [type-annos-observers] 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