From mernst at cs.washington.edu  Mon Nov  5 10:46:55 2012
From: mernst at cs.washington.edu (Michael Ernst)
Date: Mon, 05 Nov 2012 10:46:55 -0800 (PST)
Subject: [jsr-308-eg] Fw: Syntax for type annotations on
	fully-qualified types
In-Reply-To: <OFB386AE04.653EE1DD-ON65257AA2.0024343B-65257AA2.00246BE4@in.ibm.com>
References: <OF7B42079C.37776EF4-ON65257A9F.003CEDD4-65257A9F.003FE1C6@in.ibm.com>
	<50887591.5030806@oracle.com>
	<OFB386AE04.653EE1DD-ON65257AA2.0024343B-65257AA2.00246BE4@in.ibm.com>
Message-ID: <20121105.104655.2044156564915804106.mernst@cs.washington.edu>

It seems that we now have unanimity in preference for the
  package1.package2. @Annotation SimpleName
syntax over the
  @Annotation package1.package2.SimpleName

Initially, Werner wanted that, Alex didn't want it, and no one else
including Srikanth and me had a strong opinion.  But with Srikanth now
weighing in for the "Annotations on Simple Names" proposal and Alex
switching his vote, I have made this change.  I realize that it will make
the implementation much simpler, but it ended up being a very simple change
to the specification:
http://code.google.com/p/jsr308-langtools/source/detail?r=98096a9ae25190dc101e553e06f6be406565b246

The only thing I am unsure about is the grammar changes.  I'm slightly
hobbled there because I don't have access to the latest Java SE 8 grammar,
which treats identifiers slightly differently than the public Java SE 7
grammar does.

Thanks for re-raising this, Srikanth.

		    -Mike

From alex.buckley at oracle.com  Mon Nov  5 11:57:35 2012
From: alex.buckley at oracle.com (Alex Buckley)
Date: Mon, 05 Nov 2012 11:57:35 -0800
Subject: [jsr-308-eg] Fw: Syntax for type annotations on fully-qualified
	types
In-Reply-To: <20121105.104655.2044156564915804106.mernst@cs.washington.edu>
References: <OF7B42079C.37776EF4-ON65257A9F.003CEDD4-65257A9F.003FE1C6@in.ibm.com>
	<50887591.5030806@oracle.com>
	<OFB386AE04.653EE1DD-ON65257AA2.0024343B-65257AA2.00246BE4@in.ibm.com>
	<20121105.104655.2044156564915804106.mernst@cs.washington.edu>
Message-ID: <50981A2F.9020201@oracle.com>

On 11/5/2012 10:46 AM, Michael Ernst wrote:
> The only thing I am unsure about is the grammar changes.  I'm slightly
> hobbled there because I don't have access to the latest Java SE 8 grammar,
> which treats identifiers slightly differently than the public Java SE 7
> grammar does.

The "latest Java SE 8 grammar" is the union of the changes planned by 
JSR 335, JSR 308, and the bug 
https://jbs.oracle.com/bugs/browse/JDK-7080366. I'm not aware of changes 
to identifiers?

Alex

From mernst at cs.washington.edu  Tue Nov  6 13:07:33 2012
From: mernst at cs.washington.edu (Michael Ernst)
Date: Tue, 06 Nov 2012 13:07:33 -0800 (PST)
Subject: Improving the format of type annotation attributes
In-Reply-To: <505DD604.8050300@free.fr>
References: <505DD604.8050300@free.fr>
Message-ID: <20121106.130733.583201074821437601.mernst@cs.washington.edu>

Eric Bruneton made the following suggestion about restructuring the class
file format for

This approach combines elements of earlier proposals by John Rose, Alex
Buckley, Eric Bruneton, and others.  It seems to be the right mix.  I am
editing the JSR 308 specification to specify the below class file format
(though some of the names in the union have subsequently changed).

Thanks, Eric!

		    -Mike



> Subject: Re: Improving the format of type annotation attributes
> From: Eric Bruneton <ebruneton at free.fr>
> To: type-annotations-spec-comments at openjdk.java.net
> Date: Sat, 22 Sep 2012 17:15:16 +0200
>
> I have one comment about the "fully nested" format proposed by John
> Rose. As noted by Alex Buckley this is an "inside-out" encoding for all
> kinds of targets. For reasons that I explained previously, I think it would
> be better to have an outside-in encoding for all targets. This can be done
> with a "nested" approach too, as follows:
>
> type_annotation {
>     // New fields in JSR 308:
>     u1 target_type; // CHANGE: u1 and remove the 18 odd types
>     union {
>         typeparam_target;
>         supertype_target;
>         typeparam_bound_target;
>         empty_target;
>         methodparam_target;
>         exception_target;
>         localvar_target;
>         catch_target;
>         offset_target;
>         typearg_target;
>     } target_info;
>     type_path target_path; // ++ADDED, see below
>     // Original fields from "annotation" structure:
>     u2 type_index;
>     u2 num_element_value_pairs;
>     {
>         u2 element_name_index;
>         element_value value;
>     } element_value_pairs[num_element_value_pairs];
> }
>
> ADDED structure:
>
> struct type_path {
>     u1 path_type; // five possible values, one for each case below
>     union {
>         struct empty_path {};
>         struct array_type_path { type_path subpath; };
>         struct inner_type_path { type_path subpath; };
>         struct wildcard_path { type_path subpath; };
>         struct type_argument_path { u1 parameter_index; type_path subpath; };
>     }
> }
>
> In this way we have the annotation target first, from most significant to
> least significant parts, followed by the annotation value. From the ASM
> point of view, both this proposed format and the current "counted" format
> (with nested types numbering reversed) would be fine.
>
> Eric

From mernst at cs.washington.edu  Tue Nov  6 13:11:32 2012
From: mernst at cs.washington.edu (Michael Ernst)
Date: Tue, 06 Nov 2012 13:11:32 -0800 (PST)
Subject: Type Annotations specification updates
Message-ID: <20121106.131132.137725940224873483.mernst@cs.washington.edu>

I have made some changes to the Type Annotations (JSR 308) specification.
You can always see the current changelog at
http://jsr308-langtools.googlecode.com/hg/doc/jsr308-changes.html
and the most recent updates are these:

 * Add new target_type constants, to support lambda:
   LAMBDA_FORMAL_PARAMETER and METHOD_REFERENCE_TYPE_ARGUMENT

 * Rename target_type structure and field names.
   [See deatils in the above URL.]

The change for which I just sent out email is taking a while to integrate
into the specification, but I am working on that.

		    -Mike

From mernst at cs.washington.edu  Wed Nov  7 10:26:20 2012
From: mernst at cs.washington.edu (Michael Ernst)
Date: Wed, 07 Nov 2012 10:26:20 -0800 (PST)
Subject: Improving the format of type annotation attributes
In-Reply-To: <20121106.130733.583201074821437601.mernst@cs.washington.edu>
References: <505DD604.8050300@free.fr>
	<20121106.130733.583201074821437601.mernst@cs.washington.edu>
Message-ID: <20121107.102620.1492248274776868093.mernst@cs.washington.edu>

I have now updated the specification to account for the type_path
representation of compound types.  This made the spec shorter and simpler,
which is nice.  The changelog is at
http://jsr308-langtools.googlecode.com/hg/doc/jsr308-changes.html but
you'll want to see the actual spec in the repository instead.  (Let me know
if you want me to send you a formatted HTML or PDF version.)  Comments are
welcome, as always.

		    -Mike


> Subject: Re: Improving the format of type annotation attributes
> From: Michael Ernst <mernst at cs.washington.edu>
> To: type-annotations-spec-experts at openjdk.java.net
> Date: Tue, 06 Nov 2012 13:07:33 -0800 (PST)
>
> Eric Bruneton made the following suggestion about restructuring the class
> file format for
>
> This approach combines elements of earlier proposals by John Rose, Alex
> Buckley, Eric Bruneton, and others.  It seems to be the right mix.  I am
> editing the JSR 308 specification to specify the below class file format
> (though some of the names in the union have subsequently changed).
>
> Thanks, Eric!
>
> 		    -Mike
>
>
>
> > Subject: Re: Improving the format of type annotation attributes
> > From: Eric Bruneton <ebruneton at free.fr>
> > To: type-annotations-spec-comments at openjdk.java.net
> > Date: Sat, 22 Sep 2012 17:15:16 +0200
> >
> > I have one comment about the "fully nested" format proposed by John
> > Rose. As noted by Alex Buckley this is an "inside-out" encoding for all
> > kinds of targets. For reasons that I explained previously, I think it would
> > be better to have an outside-in encoding for all targets. This can be done
> > with a "nested" approach too, as follows:
> >
> > type_annotation {
> >     // New fields in JSR 308:
> >     u1 target_type; // CHANGE: u1 and remove the 18 odd types
> >     union {
> >         typeparam_target;
> >         supertype_target;
> >         typeparam_bound_target;
> >         empty_target;
> >         methodparam_target;
> >         exception_target;
> >         localvar_target;
> >         catch_target;
> >         offset_target;
> >         typearg_target;
> >     } target_info;
> >     type_path target_path; // ++ADDED, see below
> >     // Original fields from "annotation" structure:
> >     u2 type_index;
> >     u2 num_element_value_pairs;
> >     {
> >         u2 element_name_index;
> >         element_value value;
> >     } element_value_pairs[num_element_value_pairs];
> > }
> >
> > ADDED structure:
> >
> > struct type_path {
> >     u1 path_type; // five possible values, one for each case below
> >     union {
> >         struct empty_path {};
> >         struct array_type_path { type_path subpath; };
> >         struct inner_type_path { type_path subpath; };
> >         struct wildcard_path { type_path subpath; };
> >         struct type_argument_path { u1 parameter_index; type_path subpath; };
> >     }
> > }
> >
> > In this way we have the annotation target first, from most significant to
> > least significant parts, followed by the annotation value. From the ASM
> > point of view, both this proposed format and the current "counted" format
> > (with nested types numbering reversed) would be fine.
> >
> > Eric

From alex.buckley at oracle.com  Wed Nov  7 10:29:22 2012
From: alex.buckley at oracle.com (Alex Buckley)
Date: Wed, 07 Nov 2012 10:29:22 -0800
Subject: Improving the format of type annotation attributes
In-Reply-To: <20121107.102620.1492248274776868093.mernst@cs.washington.edu>
References: <505DD604.8050300@free.fr>
	<20121106.130733.583201074821437601.mernst@cs.washington.edu>
	<20121107.102620.1492248274776868093.mernst@cs.washington.edu>
Message-ID: <509AA882.9030505@oracle.com>

Thanks Mike. Could you post the URLs to the PDF and HTML versions here 
please? The links in the changelog are broken.

Alex

On 11/7/2012 10:26 AM, Michael Ernst wrote:
> I have now updated the specification to account for the type_path
> representation of compound types.  This made the spec shorter and simpler,
> which is nice.  The changelog is at
> http://jsr308-langtools.googlecode.com/hg/doc/jsr308-changes.html but
> you'll want to see the actual spec in the repository instead.  (Let me know
> if you want me to send you a formatted HTML or PDF version.)  Comments are
> welcome, as always.
>
> 		    -Mike
>
>
>> Subject: Re: Improving the format of type annotation attributes
>> From: Michael Ernst <mernst at cs.washington.edu>
>> To: type-annotations-spec-experts at openjdk.java.net
>> Date: Tue, 06 Nov 2012 13:07:33 -0800 (PST)
>>
>> Eric Bruneton made the following suggestion about restructuring the class
>> file format for
>>
>> This approach combines elements of earlier proposals by John Rose, Alex
>> Buckley, Eric Bruneton, and others.  It seems to be the right mix.  I am
>> editing the JSR 308 specification to specify the below class file format
>> (though some of the names in the union have subsequently changed).
>>
>> Thanks, Eric!
>>
>> 		    -Mike
>>
>>
>>
>>> Subject: Re: Improving the format of type annotation attributes
>>> From: Eric Bruneton <ebruneton at free.fr>
>>> To: type-annotations-spec-comments at openjdk.java.net
>>> Date: Sat, 22 Sep 2012 17:15:16 +0200
>>>
>>> I have one comment about the "fully nested" format proposed by John
>>> Rose. As noted by Alex Buckley this is an "inside-out" encoding for all
>>> kinds of targets. For reasons that I explained previously, I think it would
>>> be better to have an outside-in encoding for all targets. This can be done
>>> with a "nested" approach too, as follows:
>>>
>>> type_annotation {
>>>      // New fields in JSR 308:
>>>      u1 target_type; // CHANGE: u1 and remove the 18 odd types
>>>      union {
>>>          typeparam_target;
>>>          supertype_target;
>>>          typeparam_bound_target;
>>>          empty_target;
>>>          methodparam_target;
>>>          exception_target;
>>>          localvar_target;
>>>          catch_target;
>>>          offset_target;
>>>          typearg_target;
>>>      } target_info;
>>>      type_path target_path; // ++ADDED, see below
>>>      // Original fields from "annotation" structure:
>>>      u2 type_index;
>>>      u2 num_element_value_pairs;
>>>      {
>>>          u2 element_name_index;
>>>          element_value value;
>>>      } element_value_pairs[num_element_value_pairs];
>>> }
>>>
>>> ADDED structure:
>>>
>>> struct type_path {
>>>      u1 path_type; // five possible values, one for each case below
>>>      union {
>>>          struct empty_path {};
>>>          struct array_type_path { type_path subpath; };
>>>          struct inner_type_path { type_path subpath; };
>>>          struct wildcard_path { type_path subpath; };
>>>          struct type_argument_path { u1 parameter_index; type_path subpath; };
>>>      }
>>> }
>>>
>>> In this way we have the annotation target first, from most significant to
>>> least significant parts, followed by the annotation value. From the ASM
>>> point of view, both this proposed format and the current "counted" format
>>> (with nested types numbering reversed) would be fine.
>>>
>>> Eric

From mernst at cs.washington.edu  Wed Nov  7 10:36:08 2012
From: mernst at cs.washington.edu (Michael Ernst)
Date: Wed, 07 Nov 2012 10:36:08 -0800 (PST)
Subject: Improving the format of type annotation attributes
In-Reply-To: <509AA882.9030505@oracle.com>
References: <20121106.130733.583201074821437601.mernst@cs.washington.edu>
	<20121107.102620.1492248274776868093.mernst@cs.washington.edu>
	<509AA882.9030505@oracle.com>
Message-ID: <20121107.103608.795384539929347270.mernst@cs.washington.edu>

Alex-

> Thanks Mike. Could you post the URLs to the PDF and HTML versions here
> please? The links in the changelog are broken.

That is a working copy of the changelog (it's a snapshot of the current
version of the repository).  The links will work when the changelog is
posted to the website as part of a release.

I'm attaching the current version of the spec, in PDF and HTML form.
People can always generate these from the source in the Mercurial
repository, but I can also send it around.

		     Thanks,

		    -Mike


-------------- next part --------------
A non-text attachment was scrubbed...
Name: design.pdf
Type: application/pdf
Size: 216120 bytes
Desc: not available
Url : http://mail.openjdk.java.net/pipermail/type-annotations-spec-experts/attachments/20121107/678a588e/design-0001.pdf 

From alex.buckley at oracle.com  Wed Nov  7 10:47:52 2012
From: alex.buckley at oracle.com (Alex Buckley)
Date: Wed, 07 Nov 2012 10:47:52 -0800
Subject: Improving the format of type annotation attributes
In-Reply-To: <20121107.103608.795384539929347270.mernst@cs.washington.edu>
References: <20121106.130733.583201074821437601.mernst@cs.washington.edu>
	<20121107.102620.1492248274776868093.mernst@cs.washington.edu>
	<509AA882.9030505@oracle.com>
	<20121107.103608.795384539929347270.mernst@cs.washington.edu>
Message-ID: <509AACD8.7060402@oracle.com>

On 11/7/2012 10:36 AM, Michael Ernst wrote:
> That is a working copy of the changelog (it's a snapshot of the current
> version of the repository).  The links will work when the changelog is
> posted to the website as part of a release.

To clarify for other EG members: you mean a release of the U.W. Checker 
Framework, not the release of a Java SE artifact.

> I'm attaching the current version of the spec, in PDF and HTML form.
> People can always generate these from the source in the Mercurial
> repository, but I can also send it around.

Thanks, it is always good for EG members to get IP from this mailing 
list and not from independent sites.

Alex

From mernst at cs.washington.edu  Wed Nov  7 10:54:53 2012
From: mernst at cs.washington.edu (Michael Ernst)
Date: Wed, 07 Nov 2012 10:54:53 -0800 (PST)
Subject: Improving the format of type annotation attributes
In-Reply-To: <509AACD8.7060402@oracle.com>
References: <509AA882.9030505@oracle.com>
	<20121107.103608.795384539929347270.mernst@cs.washington.edu>
	<509AACD8.7060402@oracle.com>
Message-ID: <20121107.105453.1875432980278735996.mernst@cs.washington.edu>

Alex-

> > That is a working copy of the changelog (it's a snapshot of the current
> > version of the repository).  The links will work when the changelog is
> > posted to the website as part of a release.
>
> To clarify for other EG members: you mean a release of the U.W. Checker
> Framework, not the release of a Java SE artifact.

Sorry for my ambiguity.  I meant as part of a release of the spec to the
website http://types.cs.washington.edu/jsr308/.
This is independent of releases of:
 * the UW Checker Framework
 * the UW Type Annotations compiler
 * any Java SE artifact
 * Early Draft Reviews or any other part of the Java Community Process.

> > I'm attaching the current version of the spec, in PDF and HTML form.
> > People can always generate these from the source in the Mercurial
> > repository, but I can also send it around.
>
> Thanks, it is always good for EG members to get IP from this mailing list
> and not from independent sites.

OK.  I'll continue to send them on request, as I don't want to spam the
list with every little change.  But, this was a major and important one, so
thanks for prodding me to send it this time around.

		    -Mike

From mernst at cs.washington.edu  Wed Nov  7 11:24:53 2012
From: mernst at cs.washington.edu (Michael Ernst)
Date: Wed, 07 Nov 2012 11:24:53 -0800 (PST)
Subject: JSR 308: Class file version number
Message-ID: <20121107.112453.684674995442647379.mernst@cs.washington.edu>

A minor update:  I have specified that the class file changes are for class
file version 52 and higher.

		    -Mike

From alex.buckley at oracle.com  Tue Nov 13 18:20:46 2012
From: alex.buckley at oracle.com (Alex Buckley)
Date: Tue, 13 Nov 2012 18:20:46 -0800
Subject: Comments on the Nov 7 specification
Message-ID: <50A2FFFE.1040706@oracle.com>

Experts,

Werner Dietl sent the comments below about the spec in Mike's mail 
"Improving the format of type annotation attributes" of 11/7/12.

Most are useful clarifications to the spec, but one comment proposes an 
array rather than a tree to represent the hierarchical location of a 
type annotation in a compound type. Each level in the tree becomes the 
succeeding array entry.

The proposal has a union with a context-sensitive single member that 
would break pack200, so here is a slightly modified version:

struct type_path {
   u1              path_length;
   type_path_entry path[path_length];
}

struct type_path_entry {
   u1 type_path_kind;
     // 0: annotation is deeper in this array type
     // 1: annotation is deeper in this nested type
     // 2: annotation is on the bound of this wildcard type arg
     // 3: annotation is on the i'th type arg of this parameterized type
   u1 type_argument_index;
     // 0: ignore me
     // non-0: the 1st, 2nd, etc type arg of this parameterized type
}

I think this is fine. A further improvement would be to drop the 
type_argument_index item and encode the i'th type arg into the 
type_path_kind item. Namely, type_path_kind values >=3 represent the 
type_path_kind-2'th type arg of the current parameterized type. This 
trick is used in the stack_map_frame structure (JVMS 4.7.4).

Alex

**********

page 16:
- The values for "path_type" are not specified. Something like Fig. 1
might be overkill, but I don't just want to assume that they are 0 - 4.

- I'm not quite sure I see the advantage of the nested structure.
Couldn't we use an array instead? We are simply specifying a sequence
of steps to follow, not a complicated tree.

struct type_path_entry {
   u1 path_type;
   union {
     // empty for most, only type_argument_path has info
     u1 type_argument_index;
   }
}

struct type_path {
   u1 path_length;
   type_path_entry [ path_length ];
}

The path_length could be used instead of or in addition to ending each
path with empty_path - like we can have either C-style null-terminated
strings or Pascal-style strings with length
I would prefer using path_length without empty_path.

Then instead of:

type_argument_path { 1, type_argument_path { 0, empty path } }

we would have:

length: 2;
elements: type_argument_path, 1, type_argument_path, 0;

I think the resulting sequence of bytes would be the same (if
path_length is left off), but I would find the presentation as array a
lot simpler.
Am I missing what the advantage of this nested presentation is? If so,
I might be implementing it wrong


- On a related note, I find the representation of nested types weird. It
basically is "go one step up in the nesting". Similarly,
type_argument_path could be a "go one step right in the type
arguments" operation.
I find the solution for type arguments nicer and would suggest that we use:

   union {
     // empty for most
     u1 type_argument_index;
     u1 outer_index;
   }

The location for @M in the first example was:

inner_type_path { inner_type_path { inner_type_path { empty_path } } }

and would now simply be:

length: 1;
elements: inner_type_path, 3;

This is similar to the old way of counting, just ignoring any
array/type argument confusion and just counting the nesting. 0 is the
main modifier and left off, 1 is the first enclosing, etc. This way
the index corresponds to the number of "inner_type_path" elements in
the complicated/current way. We could use 0-based instead.


page 14:
- Section 3.3.6: I'm a bit amazed that the "throws_type_index" is a
u2, but the "method_parameter_index" is a u1. Can there really be so
many more exceptions than parameters?

- I note that annotations in the signature are stored in the
"method_info structure", whereas annotations in method bodies are
stored in "a Code attribute".
Is this an intentional difference? Or is this something that wasn't
updated yet? If it's intentional, I would find a heads-up useful,
maybe together with Fig. 1 that discusses the different categories.


page 3:
- I would put "for casts" and "for type tests" together. I would
mention that there are no runtime checks for these.

- In "for constructor invocation results":
In
   myVar . new @Tainted NestedClass
add "()" at the end.

- Point 4 already talks about receivers, before point 5 introduced the
concept and syntax for that. Maybe the order should be switched?

page 5:
- The last sentence of point 5 is the first to mention TYPE_USE. Would
it make sense to introduce the new ElementType constants earlier?

- Point 6 could mention that it uses ElementType.TYPE_PARAMETER

page 10:
- "Annotations that target instructions are _are_ those..."

- In "How Java SE 7 stores annotations" we are reminded that there are
both Runtime[In]VisibleParameterAnnotations and 
Runtime[In]VisibleAnnotations.
Would it help to highlight that in JSR 308 we do not add
Runtime[In]VisibleParameterTypeAnnotations and instead store such
annotations with the method?

page 11:
- The last paragraph of Section 3.1 should also have a reference to
Section 3.4 and give a similar overview as for the other sections.

page 12:
- Last sentence of Section 3.3 refers to generic type arguments and
arrays only. It should have the complete list with nested types, etc.

- Copy & paste mistake: Section 3.3.1 mentions
"type_parameter_bound_target" and "bound".

page 13:
- Section 3.3.2 could also mention that the index is 0-based, like
earlier and later subsections do (redundantly, I agree).

**********

From alex.buckley at oracle.com  Wed Nov 14 11:24:20 2012
From: alex.buckley at oracle.com (Alex Buckley)
Date: Wed, 14 Nov 2012 11:24:20 -0800
Subject: Comments on the Nov 7 specification
In-Reply-To: <50A2FFFE.1040706@oracle.com>
References: <50A2FFFE.1040706@oracle.com>
Message-ID: <50A3EFE4.8060805@oracle.com>

Experts,

Werner has proposed (see below) an optimization so that multiple 
"levels" of the same kind of compound type can be "jumped" in one go. 
That is, rather than a type_path_entry for each and every successive 
type constructor ([] for array types, . for nested types, < for type 
arguments, and ? ... for wildcard bounds),

The Java language imposes no limit on the number of dimensions of an 
array type, the depth of nesting of a nested type, or the number of type 
parameters of a generic type (and hence the number of type arguments in 
a parameterized type). But the JVM is more limited, so it would be OK 
for type_path_entry to collapse to a single u2 whose value is 
partitioned as 0-999 for "walk array type constructors", 1000-1999 for 
"walk nested type constructors", 2000 for "look at the wildcard bound" 
(unless we support multiple bounds in future), and 3000-3999 for "look 
at the i-2999'th type argument".

Alex

**********

how about:

struct type_path_entry {
   u1 type_path_kind;
     // 0: annotation is deeper in this array type
     // 1: annotation is deeper in this nested type
     // 2: annotation is on the bound of this wildcard type arg
     // 3: annotation is on the i'th type arg of this parameterized type
   u1 additional_index;
     // 0: ignore me
     // non-0: the 1st, 2nd, etc array index, nested type, or type arg
of this parameterized type
}

That is, we use the additional_index (better name?) as argument for
arrays, nested types, and type arguments.

Instead of

array_type_path { array_type_path {array_type_path {}}}

one can then write:

length: 1
elements: array_type_path, 3.

This applies in addition to the comment I already had about nested
types, where I also think it would be easier to use a flag and an
argument instead of repeating a flag multiple times.
This would make handling of arrays, nested types, and type arguments
nicely uniform.

I like re-using one field instead of having a context-dependent union.

About encoding everything within the flag: this will prevent any
future extension of the type_path_kind.
Also, how many type parameters can a class/method have? Are 253
possible values enough? (Similarly for the nesting-depth of arrays and
types.)

**********

On 11/13/2012 6:20 PM, Alex Buckley wrote:
> Experts,
>
> Werner Dietl sent the comments below about the spec in Mike's mail
> "Improving the format of type annotation attributes" of 11/7/12.
>
> Most are useful clarifications to the spec, but one comment proposes an
> array rather than a tree to represent the hierarchical location of a
> type annotation in a compound type. Each level in the tree becomes the
> succeeding array entry.
>
> The proposal has a union with a context-sensitive single member that
> would break pack200, so here is a slightly modified version:
>
> struct type_path {
>    u1              path_length;
>    type_path_entry path[path_length];
> }
>
> struct type_path_entry {
>    u1 type_path_kind;
>      // 0: annotation is deeper in this array type
>      // 1: annotation is deeper in this nested type
>      // 2: annotation is on the bound of this wildcard type arg
>      // 3: annotation is on the i'th type arg of this parameterized type
>    u1 type_argument_index;
>      // 0: ignore me
>      // non-0: the 1st, 2nd, etc type arg of this parameterized type
> }
>
> I think this is fine. A further improvement would be to drop the
> type_argument_index item and encode the i'th type arg into the
> type_path_kind item. Namely, type_path_kind values >=3 represent the
> type_path_kind-2'th type arg of the current parameterized type. This
> trick is used in the stack_map_frame structure (JVMS 4.7.4).
>
> Alex
>
> **********
>
> page 16:
> - The values for "path_type" are not specified. Something like Fig. 1
> might be overkill, but I don't just want to assume that they are 0 - 4.
>
> - I'm not quite sure I see the advantage of the nested structure.
> Couldn't we use an array instead? We are simply specifying a sequence
> of steps to follow, not a complicated tree.
>
> struct type_path_entry {
>    u1 path_type;
>    union {
>      // empty for most, only type_argument_path has info
>      u1 type_argument_index;
>    }
> }
>
> struct type_path {
>    u1 path_length;
>    type_path_entry [ path_length ];
> }
>
> The path_length could be used instead of or in addition to ending each
> path with empty_path - like we can have either C-style null-terminated
> strings or Pascal-style strings with length
> I would prefer using path_length without empty_path.
>
> Then instead of:
>
> type_argument_path { 1, type_argument_path { 0, empty path } }
>
> we would have:
>
> length: 2;
> elements: type_argument_path, 1, type_argument_path, 0;
>
> I think the resulting sequence of bytes would be the same (if
> path_length is left off), but I would find the presentation as array a
> lot simpler.
> Am I missing what the advantage of this nested presentation is? If so,
> I might be implementing it wrong
>
>
> - On a related note, I find the representation of nested types weird. It
> basically is "go one step up in the nesting". Similarly,
> type_argument_path could be a "go one step right in the type
> arguments" operation.
> I find the solution for type arguments nicer and would suggest that we use:
>
>    union {
>      // empty for most
>      u1 type_argument_index;
>      u1 outer_index;
>    }
>
> The location for @M in the first example was:
>
> inner_type_path { inner_type_path { inner_type_path { empty_path } } }
>
> and would now simply be:
>
> length: 1;
> elements: inner_type_path, 3;
>
> This is similar to the old way of counting, just ignoring any
> array/type argument confusion and just counting the nesting. 0 is the
> main modifier and left off, 1 is the first enclosing, etc. This way
> the index corresponds to the number of "inner_type_path" elements in
> the complicated/current way. We could use 0-based instead.
>
>
> page 14:
> - Section 3.3.6: I'm a bit amazed that the "throws_type_index" is a
> u2, but the "method_parameter_index" is a u1. Can there really be so
> many more exceptions than parameters?
>
> - I note that annotations in the signature are stored in the
> "method_info structure", whereas annotations in method bodies are
> stored in "a Code attribute".
> Is this an intentional difference? Or is this something that wasn't
> updated yet? If it's intentional, I would find a heads-up useful,
> maybe together with Fig. 1 that discusses the different categories.
>
>
> page 3:
> - I would put "for casts" and "for type tests" together. I would
> mention that there are no runtime checks for these.
>
> - In "for constructor invocation results":
> In
>    myVar . new @Tainted NestedClass
> add "()" at the end.
>
> - Point 4 already talks about receivers, before point 5 introduced the
> concept and syntax for that. Maybe the order should be switched?
>
> page 5:
> - The last sentence of point 5 is the first to mention TYPE_USE. Would
> it make sense to introduce the new ElementType constants earlier?
>
> - Point 6 could mention that it uses ElementType.TYPE_PARAMETER
>
> page 10:
> - "Annotations that target instructions are _are_ those..."
>
> - In "How Java SE 7 stores annotations" we are reminded that there are
> both Runtime[In]VisibleParameterAnnotations and
> Runtime[In]VisibleAnnotations.
> Would it help to highlight that in JSR 308 we do not add
> Runtime[In]VisibleParameterTypeAnnotations and instead store such
> annotations with the method?
>
> page 11:
> - The last paragraph of Section 3.1 should also have a reference to
> Section 3.4 and give a similar overview as for the other sections.
>
> page 12:
> - Last sentence of Section 3.3 refers to generic type arguments and
> arrays only. It should have the complete list with nested types, etc.
>
> - Copy & paste mistake: Section 3.3.1 mentions
> "type_parameter_bound_target" and "bound".
>
> page 13:
> - Section 3.3.2 could also mention that the index is 0-based, like
> earlier and later subsections do (redundantly, I agree).
>
> **********

From mernst at cs.washington.edu  Mon Nov 19 22:33:56 2012
From: mernst at cs.washington.edu (Michael Ernst)
Date: Mon, 19 Nov 2012 22:33:56 -0800 (PST)
Subject: Comments on the Nov 7 specification
In-Reply-To: <50A3EFE4.8060805@oracle.com>
References: <50A2FFFE.1040706@oracle.com>
	<50A3EFE4.8060805@oracle.com>
Message-ID: <20121119.223356.2251925414892345769.mernst@cs.washington.edu>

Following up again, Werner Dietl suggested:


struct type_path {
  u1              path_length;
  type_path_entry path[path_length];
}

struct type_path_entry {
  u2 type_path_kind;
}

(Having the extra type_path_entry struct seems redundant now...)

The value of type_path_kind div 1000 determines the kind:

0: annotation is deeper in this array type
1: annotation is deeper in this nested type
2: annotation is on the bound of this wildcard type arg
3: annotation is on the i'th type arg of this parameterized type

The value of type_path_kind modulo 1000 gives the offset within that kind.
Values where modulo 1000 equals 0 are invalid.


This is more compact, but perhaps it feels even too inefficient.

Eric, we haven't heard you chime in.  Do you have an opinion on the several
alternatives we have discussed?

		    -Mike

From mernst at cs.washington.edu  Tue Nov 20 12:37:16 2012
From: mernst at cs.washington.edu (Michael Ernst)
Date: Tue, 20 Nov 2012 12:37:16 -0800 (PST)
Subject: [type-annos-observers] Comments on the Nov 7 specification
In-Reply-To: <50A67E0B.2010108@free.fr>
References: <50A67E0B.2010108@free.fr>
Message-ID: <20121120.123716.298465860904600964.mernst@cs.washington.edu>

Eric Bruneton said:

> From an ASM point of view,
> ...
> The important
> point is that all paths should be "from outside to inside" (e.g. for nested
> types, the path should go from outer to inner, not the other way around as
> proposed in the Nov 7 specification).

Eric, I'm willing to make this change, but I would like to be able to give
a more specific justification for the design choice.  Can you explain the
rationale, or what difference it makes to ASM?  Is the reason that the
identifiers appear left-to-right in the class file and you want to process
them in that order, or is it something else?

(The current numbering was starting at what I think of as the real or main
type, and then adding auxiliary information afterward, just as it does for
generics.  So "outside to inside" might need some more explanation in the
documentation.)

Thanks!

		    -Mike

From mernst at cs.washington.edu  Tue Nov 20 14:31:25 2012
From: mernst at cs.washington.edu (Michael Ernst)
Date: Tue, 20 Nov 2012 14:31:25 -0800 (PST)
Subject: [type-annos-observers] Comments on the Nov 7 specification
In-Reply-To: <CAJYRO=6RyQ0+7=gK8EafGdoU1yKbEbwWf0AqEVoQMw0+cX_LGg@mail.gmail.com>
References: <50A2FFFE.1040706@oracle.com>
	<CAJYRO=6RyQ0+7=gK8EafGdoU1yKbEbwWf0AqEVoQMw0+cX_LGg@mail.gmail.com>
Message-ID: <20121120.143125.1963478024341236538.mernst@cs.washington.edu>

Werner-

We will go with this proposal.  I'll write it up in the specification soon.

		    -Mike


> Subject: Re: [type-annos-observers] Comments on the Nov 7 specification
> From: Werner Dietl <wdietl at gmail.com>
> To: Alex Buckley <alex.buckley at oracle.com>,
>         type-annotations-spec-comments at openjdk.java.net
> Date: Tue, 13 Nov 2012 18:49:33 -0800
>
> Alex, experts,
>
> how about:
>
> struct type_path_entry {
>   u1 type_path_kind;
>     // 0: annotation is deeper in this array type
>     // 1: annotation is deeper in this nested type
>     // 2: annotation is on the bound of this wildcard type arg
>     // 3: annotation is on the i'th type arg of this parameterized type
>   u1 additional_index;
>     // 0: ignore me
>     // non-0: the 1st, 2nd, etc array index, nested type, or type arg
> of this parameterized type
> }
>
> That is, we use the additional_index (better name?) as argument for
> arrays, nested types, and type arguments.
>
> Instead of
>
> array_type_path { array_type_path {array_type_path {}}}
>
> one can then write:
>
> length: 1
> elements: array_type_path, 3.
>
> This applies in addition to the comment I already had about nested
> types, where I also think it would be easier to use a flag and an
> argument instead of repeating a flag multiple times.
> This would make handling of arrays, nested types, and type arguments
> nicely uniform.
>
> I like re-using one field instead of having a context-dependent union.
>
> About encoding everything within the flag: this will prevent any
> future extension of the type_path_kind.
> Also, how many type parameters can a class/method have? Are 253
> possible values enough? (Similarly for the nesting-depth of arrays and
> types.)
>
> cu, WMD.
>
>
> On Tue, Nov 13, 2012 at 6:20 PM, Alex Buckley <alex.buckley at oracle.com> wrote:
> > Experts,
> >
> > Werner Dietl sent the comments below about the spec in Mike's mail
> > "Improving the format of type annotation attributes" of 11/7/12.
> >
> > Most are useful clarifications to the spec, but one comment proposes an
> > array rather than a tree to represent the hierarchical location of a type
> > annotation in a compound type. Each level in the tree becomes the succeeding
> > array entry.
> >
> > The proposal has a union with a context-sensitive single member that would
> > break pack200, so here is a slightly modified version:
> >
> > struct type_path {
> >   u1              path_length;
> >   type_path_entry path[path_length];
> > }
> >
> > struct type_path_entry {
> >   u1 type_path_kind;
> >     // 0: annotation is deeper in this array type
> >     // 1: annotation is deeper in this nested type
> >     // 2: annotation is on the bound of this wildcard type arg
> >     // 3: annotation is on the i'th type arg of this parameterized type
> >   u1 type_argument_index;
> >     // 0: ignore me
> >     // non-0: the 1st, 2nd, etc type arg of this parameterized type
> > }
> >
> > I think this is fine. A further improvement would be to drop the
> > type_argument_index item and encode the i'th type arg into the
> > type_path_kind item. Namely, type_path_kind values >=3 represent the
> > type_path_kind-2'th type arg of the current parameterized type. This trick
> > is used in the stack_map_frame structure (JVMS 4.7.4).
> >
> > Alex
> >
> > **********
> >
> > page 16:
> > - The values for "path_type" are not specified. Something like Fig. 1
> > might be overkill, but I don't just want to assume that they are 0 - 4.
> >
> > - I'm not quite sure I see the advantage of the nested structure.
> > Couldn't we use an array instead? We are simply specifying a sequence
> > of steps to follow, not a complicated tree.
> >
> > struct type_path_entry {
> >   u1 path_type;
> >   union {
> >     // empty for most, only type_argument_path has info
> >     u1 type_argument_index;
> >   }
> > }
> >
> > struct type_path {
> >   u1 path_length;
> >   type_path_entry [ path_length ];
> > }
> >
> > The path_length could be used instead of or in addition to ending each
> > path with empty_path - like we can have either C-style null-terminated
> > strings or Pascal-style strings with length
> > I would prefer using path_length without empty_path.
> >
> > Then instead of:
> >
> > type_argument_path { 1, type_argument_path { 0, empty path } }
> >
> > we would have:
> >
> > length: 2;
> > elements: type_argument_path, 1, type_argument_path, 0;
> >
> > I think the resulting sequence of bytes would be the same (if
> > path_length is left off), but I would find the presentation as array a
> > lot simpler.
> > Am I missing what the advantage of this nested presentation is? If so,
> > I might be implementing it wrong
> >
> >
> > - On a related note, I find the representation of nested types weird. It
> > basically is "go one step up in the nesting". Similarly,
> > type_argument_path could be a "go one step right in the type
> > arguments" operation.
> > I find the solution for type arguments nicer and would suggest that we use:
> >
> >   union {
> >     // empty for most
> >     u1 type_argument_index;
> >     u1 outer_index;
> >   }
> >
> > The location for @M in the first example was:
> >
> > inner_type_path { inner_type_path { inner_type_path { empty_path } } }
> >
> > and would now simply be:
> >
> > length: 1;
> > elements: inner_type_path, 3;
> >
> > This is similar to the old way of counting, just ignoring any
> > array/type argument confusion and just counting the nesting. 0 is the
> > main modifier and left off, 1 is the first enclosing, etc. This way
> > the index corresponds to the number of "inner_type_path" elements in
> > the complicated/current way. We could use 0-based instead.
> >
> >
> > page 14:
> > - Section 3.3.6: I'm a bit amazed that the "throws_type_index" is a
> > u2, but the "method_parameter_index" is a u1. Can there really be so
> > many more exceptions than parameters?
> >
> > - I note that annotations in the signature are stored in the
> > "method_info structure", whereas annotations in method bodies are
> > stored in "a Code attribute".
> > Is this an intentional difference? Or is this something that wasn't
> > updated yet? If it's intentional, I would find a heads-up useful,
> > maybe together with Fig. 1 that discusses the different categories.
> >
> >
> > page 3:
> > - I would put "for casts" and "for type tests" together. I would
> > mention that there are no runtime checks for these.
> >
> > - In "for constructor invocation results":
> > In
> >   myVar . new @Tainted NestedClass
> > add "()" at the end.
> >
> > - Point 4 already talks about receivers, before point 5 introduced the
> > concept and syntax for that. Maybe the order should be switched?
> >
> > page 5:
> > - The last sentence of point 5 is the first to mention TYPE_USE. Would
> > it make sense to introduce the new ElementType constants earlier?
> >
> > - Point 6 could mention that it uses ElementType.TYPE_PARAMETER
> >
> > page 10:
> > - "Annotations that target instructions are _are_ those..."
> >
> > - In "How Java SE 7 stores annotations" we are reminded that there are
> > both Runtime[In]VisibleParameterAnnotations and
> > Runtime[In]VisibleAnnotations.
> > Would it help to highlight that in JSR 308 we do not add
> > Runtime[In]VisibleParameterTypeAnnotations and instead store such
> > annotations with the method?
> >
> > page 11:
> > - The last paragraph of Section 3.1 should also have a reference to
> > Section 3.4 and give a similar overview as for the other sections.
> >
> > page 12:
> > - Last sentence of Section 3.3 refers to generic type arguments and
> > arrays only. It should have the complete list with nested types, etc.
> >
> > - Copy & paste mistake: Section 3.3.1 mentions
> > "type_parameter_bound_target" and "bound".
> >
> > page 13:
> > - Section 3.3.2 could also mention that the index is 0-based, like
> > earlier and later subsections do (redundantly, I agree).
> >
> > **********
>
>
>
> --
> http://www.google.com/profiles/wdietl

From alex.buckley at oracle.com  Tue Nov 20 14:35:16 2012
From: alex.buckley at oracle.com (Alex Buckley)
Date: Tue, 20 Nov 2012 14:35:16 -0800
Subject: [type-annos-observers] Comments on the Nov 7 specification
In-Reply-To: <20121120.143125.1963478024341236538.mernst@cs.washington.edu>
References: <50A2FFFE.1040706@oracle.com>
	<CAJYRO=6RyQ0+7=gK8EafGdoU1yKbEbwWf0AqEVoQMw0+cX_LGg@mail.gmail.com>
	<20121120.143125.1963478024341236538.mernst@cs.washington.edu>
Message-ID: <50AC05A4.6060904@oracle.com>

Watch out for the meaning of the second u1. We want the second u1 to 
only be effective for type arguments (to identify the i'th type 
argument). The second u1 must be 0 if type_path_kind indicates an array 
type, nested type, or bound of a wildcard type argument. We don't want 
to "skip" levels of a nested type or array type.

struct type_path_entry {
   u1 type_path_kind;
     // 0: annotation is deeper in this array type
     // 1: annotation is deeper in this nested type
     // 2: annotation is on the bound of this wildcard type arg
     // 3: annotation is on the i'th type arg of this parameterized type
   u1 type_argument_index;
     // 0: ignore me
     // non-0: the 1st, 2nd, etc type arg of this parameterized type
}

And to be clear, we want two u1's in this structure, and not a u2 with 
partitioned values.

Alex

On 11/20/2012 2:31 PM, Michael Ernst wrote:
> Werner-
>
> We will go with this proposal.  I'll write it up in the specification soon.
>
> 		    -Mike
>
>
>> Subject: Re: [type-annos-observers] Comments on the Nov 7 specification
>> From: Werner Dietl <wdietl at gmail.com>
>> To: Alex Buckley <alex.buckley at oracle.com>,
>>          type-annotations-spec-comments at openjdk.java.net
>> Date: Tue, 13 Nov 2012 18:49:33 -0800
>>
>> Alex, experts,
>>
>> how about:
>>
>> struct type_path_entry {
>>    u1 type_path_kind;
>>      // 0: annotation is deeper in this array type
>>      // 1: annotation is deeper in this nested type
>>      // 2: annotation is on the bound of this wildcard type arg
>>      // 3: annotation is on the i'th type arg of this parameterized type
>>    u1 additional_index;
>>      // 0: ignore me
>>      // non-0: the 1st, 2nd, etc array index, nested type, or type arg
>> of this parameterized type
>> }
>>
>> That is, we use the additional_index (better name?) as argument for
>> arrays, nested types, and type arguments.
>>
>> Instead of
>>
>> array_type_path { array_type_path {array_type_path {}}}
>>
>> one can then write:
>>
>> length: 1
>> elements: array_type_path, 3.
>>
>> This applies in addition to the comment I already had about nested
>> types, where I also think it would be easier to use a flag and an
>> argument instead of repeating a flag multiple times.
>> This would make handling of arrays, nested types, and type arguments
>> nicely uniform.
>>
>> I like re-using one field instead of having a context-dependent union.
>>
>> About encoding everything within the flag: this will prevent any
>> future extension of the type_path_kind.
>> Also, how many type parameters can a class/method have? Are 253
>> possible values enough? (Similarly for the nesting-depth of arrays and
>> types.)
>>
>> cu, WMD.
>>
>>
>> On Tue, Nov 13, 2012 at 6:20 PM, Alex Buckley <alex.buckley at oracle.com> wrote:
>>> Experts,
>>>
>>> Werner Dietl sent the comments below about the spec in Mike's mail
>>> "Improving the format of type annotation attributes" of 11/7/12.
>>>
>>> Most are useful clarifications to the spec, but one comment proposes an
>>> array rather than a tree to represent the hierarchical location of a type
>>> annotation in a compound type. Each level in the tree becomes the succeeding
>>> array entry.
>>>
>>> The proposal has a union with a context-sensitive single member that would
>>> break pack200, so here is a slightly modified version:
>>>
>>> struct type_path {
>>>    u1              path_length;
>>>    type_path_entry path[path_length];
>>> }
>>>
>>> struct type_path_entry {
>>>    u1 type_path_kind;
>>>      // 0: annotation is deeper in this array type
>>>      // 1: annotation is deeper in this nested type
>>>      // 2: annotation is on the bound of this wildcard type arg
>>>      // 3: annotation is on the i'th type arg of this parameterized type
>>>    u1 type_argument_index;
>>>      // 0: ignore me
>>>      // non-0: the 1st, 2nd, etc type arg of this parameterized type
>>> }
>>>
>>> I think this is fine. A further improvement would be to drop the
>>> type_argument_index item and encode the i'th type arg into the
>>> type_path_kind item. Namely, type_path_kind values >=3 represent the
>>> type_path_kind-2'th type arg of the current parameterized type. This trick
>>> is used in the stack_map_frame structure (JVMS 4.7.4).
>>>
>>> Alex
>>>
>>> **********
>>>
>>> page 16:
>>> - The values for "path_type" are not specified. Something like Fig. 1
>>> might be overkill, but I don't just want to assume that they are 0 - 4.
>>>
>>> - I'm not quite sure I see the advantage of the nested structure.
>>> Couldn't we use an array instead? We are simply specifying a sequence
>>> of steps to follow, not a complicated tree.
>>>
>>> struct type_path_entry {
>>>    u1 path_type;
>>>    union {
>>>      // empty for most, only type_argument_path has info
>>>      u1 type_argument_index;
>>>    }
>>> }
>>>
>>> struct type_path {
>>>    u1 path_length;
>>>    type_path_entry [ path_length ];
>>> }
>>>
>>> The path_length could be used instead of or in addition to ending each
>>> path with empty_path - like we can have either C-style null-terminated
>>> strings or Pascal-style strings with length
>>> I would prefer using path_length without empty_path.
>>>
>>> Then instead of:
>>>
>>> type_argument_path { 1, type_argument_path { 0, empty path } }
>>>
>>> we would have:
>>>
>>> length: 2;
>>> elements: type_argument_path, 1, type_argument_path, 0;
>>>
>>> I think the resulting sequence of bytes would be the same (if
>>> path_length is left off), but I would find the presentation as array a
>>> lot simpler.
>>> Am I missing what the advantage of this nested presentation is? If so,
>>> I might be implementing it wrong
>>>
>>>
>>> - On a related note, I find the representation of nested types weird. It
>>> basically is "go one step up in the nesting". Similarly,
>>> type_argument_path could be a "go one step right in the type
>>> arguments" operation.
>>> I find the solution for type arguments nicer and would suggest that we use:
>>>
>>>    union {
>>>      // empty for most
>>>      u1 type_argument_index;
>>>      u1 outer_index;
>>>    }
>>>
>>> The location for @M in the first example was:
>>>
>>> inner_type_path { inner_type_path { inner_type_path { empty_path } } }
>>>
>>> and would now simply be:
>>>
>>> length: 1;
>>> elements: inner_type_path, 3;
>>>
>>> This is similar to the old way of counting, just ignoring any
>>> array/type argument confusion and just counting the nesting. 0 is the
>>> main modifier and left off, 1 is the first enclosing, etc. This way
>>> the index corresponds to the number of "inner_type_path" elements in
>>> the complicated/current way. We could use 0-based instead.
>>>
>>>
>>> page 14:
>>> - Section 3.3.6: I'm a bit amazed that the "throws_type_index" is a
>>> u2, but the "method_parameter_index" is a u1. Can there really be so
>>> many more exceptions than parameters?
>>>
>>> - I note that annotations in the signature are stored in the
>>> "method_info structure", whereas annotations in method bodies are
>>> stored in "a Code attribute".
>>> Is this an intentional difference? Or is this something that wasn't
>>> updated yet? If it's intentional, I would find a heads-up useful,
>>> maybe together with Fig. 1 that discusses the different categories.
>>>
>>>
>>> page 3:
>>> - I would put "for casts" and "for type tests" together. I would
>>> mention that there are no runtime checks for these.
>>>
>>> - In "for constructor invocation results":
>>> In
>>>    myVar . new @Tainted NestedClass
>>> add "()" at the end.
>>>
>>> - Point 4 already talks about receivers, before point 5 introduced the
>>> concept and syntax for that. Maybe the order should be switched?
>>>
>>> page 5:
>>> - The last sentence of point 5 is the first to mention TYPE_USE. Would
>>> it make sense to introduce the new ElementType constants earlier?
>>>
>>> - Point 6 could mention that it uses ElementType.TYPE_PARAMETER
>>>
>>> page 10:
>>> - "Annotations that target instructions are _are_ those..."
>>>
>>> - In "How Java SE 7 stores annotations" we are reminded that there are
>>> both Runtime[In]VisibleParameterAnnotations and
>>> Runtime[In]VisibleAnnotations.
>>> Would it help to highlight that in JSR 308 we do not add
>>> Runtime[In]VisibleParameterTypeAnnotations and instead store such
>>> annotations with the method?
>>>
>>> page 11:
>>> - The last paragraph of Section 3.1 should also have a reference to
>>> Section 3.4 and give a similar overview as for the other sections.
>>>
>>> page 12:
>>> - Last sentence of Section 3.3 refers to generic type arguments and
>>> arrays only. It should have the complete list with nested types, etc.
>>>
>>> - Copy & paste mistake: Section 3.3.1 mentions
>>> "type_parameter_bound_target" and "bound".
>>>
>>> page 13:
>>> - Section 3.3.2 could also mention that the index is 0-based, like
>>> earlier and later subsections do (redundantly, I agree).
>>>
>>> **********
>>
>>
>>
>> --
>> http://www.google.com/profiles/wdietl

From alex.buckley at oracle.com  Tue Nov 20 14:54:54 2012
From: alex.buckley at oracle.com (Alex Buckley)
Date: Tue, 20 Nov 2012 14:54:54 -0800
Subject: [type-annos-observers] Comments on the Nov 7 specification
In-Reply-To: <CAJYRO=7+YAYS8JM3hVi9iLMhS_u6JWtM6fz-sqpwEUytYoPTxg@mail.gmail.com>
References: <50A2FFFE.1040706@oracle.com>
	<CAJYRO=6RyQ0+7=gK8EafGdoU1yKbEbwWf0AqEVoQMw0+cX_LGg@mail.gmail.com>
	<20121120.143125.1963478024341236538.mernst@cs.washington.edu>
	<50AC05A4.6060904@oracle.com>
	<CAJYRO=7+YAYS8JM3hVi9iLMhS_u6JWtM6fz-sqpwEUytYoPTxg@mail.gmail.com>
Message-ID: <50AC0A3E.4040001@oracle.com>

Mike and I just discussed the proposals on the phone and agreed not to 
allow "skipping" the levels of a compound type. You need an array entry 
for each "step" being taken in the path. (type_path.path_length will be 
valuable to tools and humans.) The second u1 therefore has no meaning 
if the first u1 is "visit nested type" or "visit component type" (or 
"visit wildcard type argument's bound", for that matter).

Alex

On Tuesday, November 20, 2012 2:44:50 PM, Werner Dietl wrote:
> Alex,
>
> why don't we use the second u1 for arrays and nested types?
> Mike's message was that we take the proposal that uses
> "additional_index", which we could call "type_path_index" or
> "type_path_offset".
> It seems much more natural to use that field consistently for arrays,
> nested types, and type arguments.
>
> I'm fine with using two separate u1s. Having 256 type arguments,
> arrays, or nesting depth should be enough.
>
> cu, WMD.
>
>
> On Tue, Nov 20, 2012 at 2:35 PM, Alex Buckley <alex.buckley at oracle.com> wrote:
>> Watch out for the meaning of the second u1. We want the second u1 to only be
>> effective for type arguments (to identify the i'th type argument). The
>> second u1 must be 0 if type_path_kind indicates an array type, nested type,
>> or bound of a wildcard type argument. We don't want to "skip" levels of a
>> nested type or array type.
>>
>>
>> struct type_path_entry {
>>    u1 type_path_kind;
>>      // 0: annotation is deeper in this array type
>>      // 1: annotation is deeper in this nested type
>>      // 2: annotation is on the bound of this wildcard type arg
>>      // 3: annotation is on the i'th type arg of this parameterized type
>>    u1 type_argument_index;
>>      // 0: ignore me
>>      // non-0: the 1st, 2nd, etc type arg of this parameterized type
>> }
>>
>> And to be clear, we want two u1's in this structure, and not a u2 with
>> partitioned values.
>>
>> Alex
>>
>>
>> On 11/20/2012 2:31 PM, Michael Ernst wrote:
>>>
>>> Werner-
>>>
>>> We will go with this proposal.  I'll write it up in the specification
>>> soon.
>>>
>>>                      -Mike
>>>
>>>
>>>> Subject: Re: [type-annos-observers] Comments on the Nov 7 specification
>>>> From: Werner Dietl <wdietl at gmail.com>
>>>> To: Alex Buckley <alex.buckley at oracle.com>,
>>>>           type-annotations-spec-comments at openjdk.java.net
>>>> Date: Tue, 13 Nov 2012 18:49:33 -0800
>>>>
>>>> Alex, experts,
>>>>
>>>> how about:
>>>>
>>>> struct type_path_entry {
>>>>     u1 type_path_kind;
>>>>       // 0: annotation is deeper in this array type
>>>>       // 1: annotation is deeper in this nested type
>>>>       // 2: annotation is on the bound of this wildcard type arg
>>>>       // 3: annotation is on the i'th type arg of this parameterized type
>>>>     u1 additional_index;
>>>>       // 0: ignore me
>>>>       // non-0: the 1st, 2nd, etc array index, nested type, or type arg
>>>> of this parameterized type
>>>> }
>>>>
>>>> That is, we use the additional_index (better name?) as argument for
>>>> arrays, nested types, and type arguments.
>>>>
>>>> Instead of
>>>>
>>>> array_type_path { array_type_path {array_type_path {}}}
>>>>
>>>> one can then write:
>>>>
>>>> length: 1
>>>> elements: array_type_path, 3.
>>>>
>>>> This applies in addition to the comment I already had about nested
>>>> types, where I also think it would be easier to use a flag and an
>>>> argument instead of repeating a flag multiple times.
>>>> This would make handling of arrays, nested types, and type arguments
>>>> nicely uniform.
>>>>
>>>> I like re-using one field instead of having a context-dependent union.
>>>>
>>>> About encoding everything within the flag: this will prevent any
>>>> future extension of the type_path_kind.
>>>> Also, how many type parameters can a class/method have? Are 253
>>>> possible values enough? (Similarly for the nesting-depth of arrays and
>>>> types.)
>>>>
>>>> cu, WMD.
>>>>
>>>>
>>>> On Tue, Nov 13, 2012 at 6:20 PM, Alex Buckley <alex.buckley at oracle.com>
>>>> wrote:
>>>>>
>>>>> Experts,
>>>>>
>>>>> Werner Dietl sent the comments below about the spec in Mike's mail
>>>>> "Improving the format of type annotation attributes" of 11/7/12.
>>>>>
>>>>> Most are useful clarifications to the spec, but one comment proposes an
>>>>> array rather than a tree to represent the hierarchical location of a
>>>>> type
>>>>> annotation in a compound type. Each level in the tree becomes the
>>>>> succeeding
>>>>> array entry.
>>>>>
>>>>> The proposal has a union with a context-sensitive single member that
>>>>> would
>>>>> break pack200, so here is a slightly modified version:
>>>>>
>>>>> struct type_path {
>>>>>     u1              path_length;
>>>>>     type_path_entry path[path_length];
>>>>> }
>>>>>
>>>>> struct type_path_entry {
>>>>>     u1 type_path_kind;
>>>>>       // 0: annotation is deeper in this array type
>>>>>       // 1: annotation is deeper in this nested type
>>>>>       // 2: annotation is on the bound of this wildcard type arg
>>>>>       // 3: annotation is on the i'th type arg of this parameterized type
>>>>>     u1 type_argument_index;
>>>>>       // 0: ignore me
>>>>>       // non-0: the 1st, 2nd, etc type arg of this parameterized type
>>>>> }
>>>>>
>>>>> I think this is fine. A further improvement would be to drop the
>>>>> type_argument_index item and encode the i'th type arg into the
>>>>> type_path_kind item. Namely, type_path_kind values >=3 represent the
>>>>> type_path_kind-2'th type arg of the current parameterized type. This
>>>>> trick
>>>>> is used in the stack_map_frame structure (JVMS 4.7.4).
>>>>>
>>>>> Alex
>>>>>
>>>>> **********
>>>>>
>>>>> page 16:
>>>>> - The values for "path_type" are not specified. Something like Fig. 1
>>>>> might be overkill, but I don't just want to assume that they are 0 - 4.
>>>>>
>>>>> - I'm not quite sure I see the advantage of the nested structure.
>>>>> Couldn't we use an array instead? We are simply specifying a sequence
>>>>> of steps to follow, not a complicated tree.
>>>>>
>>>>> struct type_path_entry {
>>>>>     u1 path_type;
>>>>>     union {
>>>>>       // empty for most, only type_argument_path has info
>>>>>       u1 type_argument_index;
>>>>>     }
>>>>> }
>>>>>
>>>>> struct type_path {
>>>>>     u1 path_length;
>>>>>     type_path_entry [ path_length ];
>>>>> }
>>>>>
>>>>> The path_length could be used instead of or in addition to ending each
>>>>> path with empty_path - like we can have either C-style null-terminated
>>>>> strings or Pascal-style strings with length
>>>>> I would prefer using path_length without empty_path.
>>>>>
>>>>> Then instead of:
>>>>>
>>>>> type_argument_path { 1, type_argument_path { 0, empty path } }
>>>>>
>>>>> we would have:
>>>>>
>>>>> length: 2;
>>>>> elements: type_argument_path, 1, type_argument_path, 0;
>>>>>
>>>>> I think the resulting sequence of bytes would be the same (if
>>>>> path_length is left off), but I would find the presentation as array a
>>>>> lot simpler.
>>>>> Am I missing what the advantage of this nested presentation is? If so,
>>>>> I might be implementing it wrong
>>>>>
>>>>>
>>>>> - On a related note, I find the representation of nested types weird. It
>>>>> basically is "go one step up in the nesting". Similarly,
>>>>> type_argument_path could be a "go one step right in the type
>>>>> arguments" operation.
>>>>> I find the solution for type arguments nicer and would suggest that we
>>>>> use:
>>>>>
>>>>>     union {
>>>>>       // empty for most
>>>>>       u1 type_argument_index;
>>>>>       u1 outer_index;
>>>>>     }
>>>>>
>>>>> The location for @M in the first example was:
>>>>>
>>>>> inner_type_path { inner_type_path { inner_type_path { empty_path } } }
>>>>>
>>>>> and would now simply be:
>>>>>
>>>>> length: 1;
>>>>> elements: inner_type_path, 3;
>>>>>
>>>>> This is similar to the old way of counting, just ignoring any
>>>>> array/type argument confusion and just counting the nesting. 0 is the
>>>>> main modifier and left off, 1 is the first enclosing, etc. This way
>>>>> the index corresponds to the number of "inner_type_path" elements in
>>>>> the complicated/current way. We could use 0-based instead.
>>>>>
>>>>>
>>>>> page 14:
>>>>> - Section 3.3.6: I'm a bit amazed that the "throws_type_index" is a
>>>>> u2, but the "method_parameter_index" is a u1. Can there really be so
>>>>> many more exceptions than parameters?
>>>>>
>>>>> - I note that annotations in the signature are stored in the
>>>>> "method_info structure", whereas annotations in method bodies are
>>>>> stored in "a Code attribute".
>>>>> Is this an intentional difference? Or is this something that wasn't
>>>>> updated yet? If it's intentional, I would find a heads-up useful,
>>>>> maybe together with Fig. 1 that discusses the different categories.
>>>>>
>>>>>
>>>>> page 3:
>>>>> - I would put "for casts" and "for type tests" together. I would
>>>>> mention that there are no runtime checks for these.
>>>>>
>>>>> - In "for constructor invocation results":
>>>>> In
>>>>>     myVar . new @Tainted NestedClass
>>>>> add "()" at the end.
>>>>>
>>>>> - Point 4 already talks about receivers, before point 5 introduced the
>>>>> concept and syntax for that. Maybe the order should be switched?
>>>>>
>>>>> page 5:
>>>>> - The last sentence of point 5 is the first to mention TYPE_USE. Would
>>>>> it make sense to introduce the new ElementType constants earlier?
>>>>>
>>>>> - Point 6 could mention that it uses ElementType.TYPE_PARAMETER
>>>>>
>>>>> page 10:
>>>>> - "Annotations that target instructions are _are_ those..."
>>>>>
>>>>> - In "How Java SE 7 stores annotations" we are reminded that there are
>>>>> both Runtime[In]VisibleParameterAnnotations and
>>>>> Runtime[In]VisibleAnnotations.
>>>>> Would it help to highlight that in JSR 308 we do not add
>>>>> Runtime[In]VisibleParameterTypeAnnotations and instead store such
>>>>> annotations with the method?
>>>>>
>>>>> page 11:
>>>>> - The last paragraph of Section 3.1 should also have a reference to
>>>>> Section 3.4 and give a similar overview as for the other sections.
>>>>>
>>>>> page 12:
>>>>> - Last sentence of Section 3.3 refers to generic type arguments and
>>>>> arrays only. It should have the complete list with nested types, etc.
>>>>>
>>>>> - Copy & paste mistake: Section 3.3.1 mentions
>>>>> "type_parameter_bound_target" and "bound".
>>>>>
>>>>> page 13:
>>>>> - Section 3.3.2 could also mention that the index is 0-based, like
>>>>> earlier and later subsections do (redundantly, I agree).
>>>>>
>>>>> **********
>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> http://www.google.com/profiles/wdietl
>
>
>

From srikanth_sankaran at in.ibm.com  Tue Nov 20 21:07:03 2012
From: srikanth_sankaran at in.ibm.com (Srikanth S Adayapalam)
Date: Wed, 21 Nov 2012 10:37:03 +0530
Subject: [type-annos-observers] Comments on the Nov 7 specification
In-Reply-To: <20121120.143125.1963478024341236538.mernst@cs.washington.edu>
References: <50A2FFFE.1040706@oracle.com>	<CAJYRO=6RyQ0+7=gK8EafGdoU1yKbEbwWf0AqEVoQMw0+cX_LGg@mail.gmail.com>
	<20121120.143125.1963478024341236538.mernst@cs.washington.edu>
Message-ID: <OF4C13EA25.EA6D58E7-ON65257ABD.001BD2DC-65257ABD.001C2E59@in.ibm.com>

Hello !

Where is the Nov 7th dated specification as referred to in the subject 
available ? 
The latest I have is dated Jul 3rd. In Eclipse we are about to start on 
code generation
work and would really like to wok with an up to date specification if 
possible.

Thanks!
Srikanth


From alex.buckley at oracle.com  Mon Nov 26 11:47:20 2012
From: alex.buckley at oracle.com (Alex Buckley)
Date: Mon, 26 Nov 2012 11:47:20 -0800
Subject: Srikanth, your comments required please
Message-ID: <50B3C748.8010609@oracle.com>

Srikanth,

Please see the discussion on inside-out v. outside-in representation of 
nested types in the ClassFile.

We have heard from Eric Bruneton, who is used to reading constant pool 
entries with left-to-right (outside-in) structure from the ClassFile. We 
have heard from Werner, who is used to dealing with a rather 
idiosyncratic inside-out AST in a compiler.

Please chime in today with your opinion on how nested types should be 
represented in the ClassFile.

Alex

From srikanth_sankaran at in.ibm.com  Mon Nov 26 23:44:30 2012
From: srikanth_sankaran at in.ibm.com (Srikanth S Adayapalam)
Date: Tue, 27 Nov 2012 13:14:30 +0530
Subject: Srikanth, your comments required please
In-Reply-To: <50B3C748.8010609@oracle.com>
References: <50B3C748.8010609@oracle.com>
Message-ID: <OF818582FE.9D979819-ON65257AC3.002A7B38-65257AC3.002A996F@in.ibm.com>

> Please chime in today with your opinion on how nested types should be 
> represented in the ClassFile.

Not today, but within this week. Thanks Alex.

Srikanth.

From mernst at cs.washington.edu  Tue Nov 27 05:48:53 2012
From: mernst at cs.washington.edu (Michael Ernst)
Date: Tue, 27 Nov 2012 05:48:53 -0800 (PST)
Subject: [type-annos-observers] Comments on the Nov 7 specification
In-Reply-To: <50B0F5BF.20006@free.fr>
References: <50A67E0B.2010108@free.fr>
	<20121120.123716.298465860904600964.mernst@cs.washington.edu>
	<50B0F5BF.20006@free.fr>
Message-ID: <20121127.054853.2055682549219719270.mernst@cs.washington.edu>

Eric-

Thanks for the followup; I appreciate it.

We are all agreed on "outside to inside" for generics; it is definitely
superior.

Your original message and my request for clarification was about nested
types.  "Outside to inside" is ambiguous for nested types, so I think we
should avoid that terminology.  For nested types, it seems there is merit
to having paths start at the main type, then proceeding to scoping
information -- which would be similar to the preferred "outside to inside"
approach that is used for generics.

		     Thanks,

		    -Mike


> Subject: Re: [type-annos-observers] Comments on the Nov 7 specification
> From: Eric Bruneton <ebruneton at free.fr>
> To: type-annotations-spec-comments at openjdk.java.net
> Date: Sat, 24 Nov 2012 17:28:47 +0100
>
> 20/11/2012 21:37, Michael Ernst wrote:
> > Eric Bruneton said:
> >
> >>  From an ASM point of view,
> >> ...
> >> The important
> >> point is that all paths should be "from outside to inside" (e.g. for nested
> >> types, the path should go from outer to inner, not the other way around as
> >> proposed in the Nov 7 specification).
> >
> > Eric, I'm willing to make this change, but I would like to be able to give
> > a more specific justification for the design choice.  Can you explain the
> > rationale, or what difference it makes to ASM?  Is the reason that the
> > identifiers appear left-to-right in the class file and you want to process
> > them in that order, or is it something else?
>
> Right, it's basically that. For instance, consider the problem of
> extracting the part of a type signature in the class file format
> (e.g. Ljava.util.Map<+Ljava.lang.String;Ljava.util.List<Ljava.lang.Object;>;>;)
> that corresponds to a given type_path. With 'outside to inside' paths, this
> can be done with a simple recursive function, like
> extract(signature,path)
> - if empty path return signature
> - otherwise parse the first signature element from the left, check conformity
>   with first path element, and call recursively with tail of signature and
>   tail of path.
>
> With 'inside to outside' paths, you have to parse the three inner types in
> the signature to realize that
> "inner_path{inner_path{inner_path{empty_path}}}", for instance, was in fact
> the first parsed type (then you either have to save state during parsing,
> or do another parsing pass).
>
> I'm not sure I'm clear, but I hope you get the idea.
>
> Eric

From alex.buckley at oracle.com  Tue Nov 27 10:15:51 2012
From: alex.buckley at oracle.com (Alex Buckley)
Date: Tue, 27 Nov 2012 10:15:51 -0800
Subject: [type-annos-observers] Comments on the Nov 7 specification
In-Reply-To: <20121127.054853.2055682549219719270.mernst@cs.washington.edu>
References: <50A67E0B.2010108@free.fr>
	<20121120.123716.298465860904600964.mernst@cs.washington.edu>
	<50B0F5BF.20006@free.fr>
	<20121127.054853.2055682549219719270.mernst@cs.washington.edu>
Message-ID: <50B50357.5030101@oracle.com>

"main type" is not a JLS term and can be interpreted in more than one 
way. Same goes for "scoping information". There is clearly more than one 
perspective here. I am not arguing for one approach or another (though I 
do have a favorite); I am arguing for absolute clarity. Let's wait for 
Srikanth's comments.

Alex

On 11/27/2012 5:48 AM, Michael Ernst wrote:
> Eric-
>
> Thanks for the followup; I appreciate it.
>
> We are all agreed on "outside to inside" for generics; it is definitely
> superior.
>
> Your original message and my request for clarification was about nested
> types.  "Outside to inside" is ambiguous for nested types, so I think we
> should avoid that terminology.  For nested types, it seems there is merit
> to having paths start at the main type, then proceeding to scoping
> information -- which would be similar to the preferred "outside to inside"
> approach that is used for generics.
>
> 		     Thanks,
>
> 		    -Mike
>
>
>> Subject: Re: [type-annos-observers] Comments on the Nov 7 specification
>> From: Eric Bruneton <ebruneton at free.fr>
>> To: type-annotations-spec-comments at openjdk.java.net
>> Date: Sat, 24 Nov 2012 17:28:47 +0100
>>
>> 20/11/2012 21:37, Michael Ernst wrote:
>>> Eric Bruneton said:
>>>
>>>>   From an ASM point of view,
>>>> ...
>>>> The important
>>>> point is that all paths should be "from outside to inside" (e.g. for nested
>>>> types, the path should go from outer to inner, not the other way around as
>>>> proposed in the Nov 7 specification).
>>>
>>> Eric, I'm willing to make this change, but I would like to be able to give
>>> a more specific justification for the design choice.  Can you explain the
>>> rationale, or what difference it makes to ASM?  Is the reason that the
>>> identifiers appear left-to-right in the class file and you want to process
>>> them in that order, or is it something else?
>>
>> Right, it's basically that. For instance, consider the problem of
>> extracting the part of a type signature in the class file format
>> (e.g. Ljava.util.Map<+Ljava.lang.String;Ljava.util.List<Ljava.lang.Object;>;>;)
>> that corresponds to a given type_path. With 'outside to inside' paths, this
>> can be done with a simple recursive function, like
>> extract(signature,path)
>> - if empty path return signature
>> - otherwise parse the first signature element from the left, check conformity
>>    with first path element, and call recursively with tail of signature and
>>    tail of path.
>>
>> With 'inside to outside' paths, you have to parse the three inner types in
>> the signature to realize that
>> "inner_path{inner_path{inner_path{empty_path}}}", for instance, was in fact
>> the first parsed type (then you either have to save state during parsing,
>> or do another parsing pass).
>>
>> I'm not sure I'm clear, but I hope you get the idea.
>>
>> Eric

From alex.buckley at oracle.com  Tue Nov 27 15:01:10 2012
From: alex.buckley at oracle.com (Alex Buckley)
Date: Tue, 27 Nov 2012 15:01:10 -0800
Subject: Comments on annotations on exception parameters
Message-ID: <50B54636.5000206@oracle.com>

Werner Dietl suggested:

*****
In "3.3.8 Exception parameters" the JSR 308 design document from Nov.
7 2012 states that annotations on an exception parameter (e.g. ...
catch (@A Exception e) ...) are stored as an exception table index.

I'm wondering whether for uniformity this could be stored like a local
variable or resource variable, where we store the information for the
variables explicitly. Unifying this aspect would simplify both the 
specification and its implementation. Thoughts?
*****

The declaration of an exception parameter is syntactically similar to 
the declaration of a local variable or resource variable, but the JVM 
representation is different.

When an exception object is thrown, the JVM places a reference to the 
thrown object on top of the operand stack. The bytecode of an exception 
handler (i.e. a catch block) may or may not store this reference in a 
local variable. There is no compiler spec to govern the matter. For 
simple catch blocks, a compiler might be able to dup the top stack entry 
and avoid local variables entirely.

Even if a compiler stores the reference in a local variable, the live 
range of that local variable would be tricky to compute because there is 
no "end" to an exception handler. Multiple handlers for one try block 
may be compiled in such a way that they jump between themselves to share 
code.

For these reasons, and to avoid duplicating the information in 
Code.exception_table, I think 3.3.8 should continue to index the 
exception_table.

Alex

From mernst at cs.washington.edu  Tue Nov 27 20:56:39 2012
From: mernst at cs.washington.edu (Michael Ernst)
Date: Tue, 27 Nov 2012 20:56:39 -0800 (PST)
Subject: Fw: Improving the format of type annotation attributes
In-Reply-To: <OF4C13EA25.EA6D58E7-ON65257ABD.001BD2DC-65257ABD.001C2E59@in.ibm.com>
References: <CAJYRO=6RyQ0+7=gK8EafGdoU1yKbEbwWf0AqEVoQMw0+cX_LGg@mail.gmail.com>
	<20121120.143125.1963478024341236538.mernst@cs.washington.edu>
	<OF4C13EA25.EA6D58E7-ON65257ABD.001BD2DC-65257ABD.001C2E59@in.ibm.com>
Message-ID: <20121127.205639.2302713944104125509.mernst@cs.washington.edu>

Srikanth-

> Where is the Nov 7th dated specification as referred to in the subject
> available ?

It was sent to you on Nov 7th.  I've attached the email in case you missed
it.

This version is now out of date, and I'll send a newer revision shortly.

		    -Mike
-------------- next part --------------
An embedded message was scrubbed...
From: Michael Ernst <mernst at cs.washington.edu>
Subject: Re: Improving the format of type annotation attributes
Date: Wed, 07 Nov 2012 10:36:08 -0800 (PST)
Size: 293768
Url: http://mail.openjdk.java.net/pipermail/type-annotations-spec-experts/attachments/20121127/7ec18571/attachment-0001.nws 

From srikanth_sankaran at in.ibm.com  Thu Nov 29 22:03:20 2012
From: srikanth_sankaran at in.ibm.com (Srikanth S Adayapalam)
Date: Fri, 30 Nov 2012 11:33:20 +0530
Subject: [type-annos-observers] Comments on the Nov 7 specification
In-Reply-To: <50B50357.5030101@oracle.com>
References: <50A67E0B.2010108@free.fr>	<20121120.123716.298465860904600964.mernst@cs.washington.edu>
	<50B0F5BF.20006@free.fr>	<20121127.054853.2055682549219719270.mernst@cs.washington.edu>
	<50B50357.5030101@oracle.com>
Message-ID: <OFF8A28462.9DF8AB90-ON65257AC6.00202F09-65257AC6.002156F4@in.ibm.com>

> From: Alex Buckley <alex.buckley at oracle.com>
> Sent by: type-annotations-spec-experts-bounces at openjdk.java.net
> 
> "main type" is not a JLS term and can be interpreted in more than one 
> way. Same goes for "scoping information". There is clearly more than one 

> perspective here. I am not arguing for one approach or another (though I 

> do have a favorite); I am arguing for absolute clarity. Let's wait for 
> Srikanth's comments.

Since there was an earlier question about how other tools that build AST
build their ASTs: Eclipse compiler builds two altogether different ASTs: 
the so called
compiler AST and the DOM/AST. Class file generation happens from the 
former
while the latter is used by clients that want structural (as opposed to 
textual)
modifications to the program.

The type Outer.Middle.Inner (earlier mail had the order wrong as 
Outer.Inner.Middle)
gets represented in the compiler AST as a single node 
QualifiedTypeReference with
a char[][] representing the tokens that make up the types.

Annotations are similarly represented as Annotation [][].

On the DOM/AST side, we do represent the qualified type as a tree with the 
each
inner level containing the qualifying type, but this AST is not used for 
class file
generation.

I do see the point about signature decoding ASM, but bottomline: I don't 
see an overwhelming 
preference for one approach vs other from our side.

Srikanth.


> 
> Alex
> 
> On 11/27/2012 5:48 AM, Michael Ernst wrote:
> > Eric-
> >
> > Thanks for the followup; I appreciate it.
> >
> > We are all agreed on "outside to inside" for generics; it is 
definitely
> > superior.
> >
> > Your original message and my request for clarification was about 
nested
> > types.  "Outside to inside" is ambiguous for nested types, so I think 
we
> > should avoid that terminology.  For nested types, it seems there is 
merit
> > to having paths start at the main type, then proceeding to scoping
> > information -- which would be similar to the preferred "outside to 
inside"
> > approach that is used for generics.
> >
> >            Thanks,
> >
> >           -Mike
> >
> >
> >> Subject: Re: [type-annos-observers] Comments on the Nov 7 
specification
> >> From: Eric Bruneton <ebruneton at free.fr>
> >> To: type-annotations-spec-comments at openjdk.java.net
> >> Date: Sat, 24 Nov 2012 17:28:47 +0100
> >>
> >> 20/11/2012 21:37, Michael Ernst wrote:
> >>> Eric Bruneton said:
> >>>
> >>>>   From an ASM point of view,
> >>>> ...
> >>>> The important
> >>>> point is that all paths should be "from outside to inside" 
> (e.g. for nested
> >>>> types, the path should go from outer to inner, not the other 
> way around as
> >>>> proposed in the Nov 7 specification).
> >>>
> >>> Eric, I'm willing to make this change, but I would like to be able 
to give
> >>> a more specific justification for the design choice.  Can you 
explain the
> >>> rationale, or what difference it makes to ASM?  Is the reason that 
the
> >>> identifiers appear left-to-right in the class file and you want to 
process
> >>> them in that order, or is it something else?
> >>
> >> Right, it's basically that. For instance, consider the problem of
> >> extracting the part of a type signature in the class file format
> >> (e.g. Ljava.util.Map<
> +Ljava.lang.String;Ljava.util.List<Ljava.lang.Object;>;>;)
> >> that corresponds to a given type_path. With 'outside to inside' 
paths, this
> >> can be done with a simple recursive function, like
> >> extract(signature,path)
> >> - if empty path return signature
> >> - otherwise parse the first signature element from the left, 
> check conformity
> >>    with first path element, and call recursively with tail of 
signature and
> >>    tail of path.
> >>
> >> With 'inside to outside' paths, you have to parse the three inner 
types in
> >> the signature to realize that
> >> "inner_path{inner_path{inner_path{empty_path}}}", for instance, was 
in fact
> >> the first parsed type (then you either have to save state during 
parsing,
> >> or do another parsing pass).
> >>
> >> I'm not sure I'm clear, but I hope you get the idea.
> >>
> >> Eric
> 

From alex.buckley at oracle.com  Fri Nov 30 11:20:42 2012
From: alex.buckley at oracle.com (Alex Buckley)
Date: Fri, 30 Nov 2012 11:20:42 -0800
Subject: [type-annos-observers] Comments on the Nov 7 specification
In-Reply-To: <OFF8A28462.9DF8AB90-ON65257AC6.00202F09-65257AC6.002156F4@in.ibm.com>
References: <50A67E0B.2010108@free.fr>	<20121120.123716.298465860904600964.mernst@cs.washington.edu>
	<50B0F5BF.20006@free.fr>	<20121127.054853.2055682549219719270.mernst@cs.washington.edu>
	<50B50357.5030101@oracle.com>
	<OFF8A28462.9DF8AB90-ON65257AC6.00202F09-65257AC6.002156F4@in.ibm.com>
Message-ID: <50B9070A.2030900@oracle.com>

Srikanth, thanks for this information.

Mike, here is my view: I think nested types should be represented "left 
to right", so that @A, @B, and @C in:

   @A Outer. @B Middle. @C Inner

are located with these type_path_entry arrays:

   @A: -
   @B: 1(0)
   @C: 1(0), 1(0)

I recognize this is not congruent with javac's AST, but I think it is 
the right all-round representation.

Alex

On 11/29/2012 10:03 PM, Srikanth S Adayapalam wrote:
>  > From: Alex Buckley <alex.buckley at oracle.com>
>  > Sent by: type-annotations-spec-experts-bounces at openjdk.java.net
>  >
>  > "main type" is not a JLS term and can be interpreted in more than one
>  > way. Same goes for "scoping information". There is clearly more than one
>  > perspective here. I am not arguing for one approach or another (though I
>  > do have a favorite); I am arguing for absolute clarity. Let's wait for
>  > Srikanth's comments.
>
> Since there was an earlier question about how other tools that build AST
> build their ASTs: Eclipse compiler builds two altogether different ASTs:
> the so called
> compiler AST and the DOM/AST. Class file generation happens from the former
> while the latter is used by clients that want structural (as opposed to
> textual)
> modifications to the program.
>
> The type Outer.Middle.Inner (earlier mail had the order wrong as
> Outer.Inner.Middle)
> gets represented in the compiler AST as a single node
> QualifiedTypeReference with
> a char[][] representing the tokens that make up the types.
>
> Annotations are similarly represented as Annotation [][].
>
> On the DOM/AST side, we do represent the qualified type as a tree with
> the each
> inner level containing the qualifying type, but this AST is not used for
> class file
> generation.
>
> I do see the point about signature decoding ASM, but bottomline: I don't
> see an overwhelming
> preference for one approach vs other from our side.
>
> Srikanth.
>
>
>  >
>  > Alex
>  >
>  > On 11/27/2012 5:48 AM, Michael Ernst wrote:
>  > > Eric-
>  > >
>  > > Thanks for the followup; I appreciate it.
>  > >
>  > > We are all agreed on "outside to inside" for generics; it is definitely
>  > > superior.
>  > >
>  > > Your original message and my request for clarification was about nested
>  > > types.  "Outside to inside" is ambiguous for nested types, so I
> think we
>  > > should avoid that terminology.  For nested types, it seems there is
> merit
>  > > to having paths start at the main type, then proceeding to scoping
>  > > information -- which would be similar to the preferred "outside to
> inside"
>  > > approach that is used for generics.
>  > >
>  > >            Thanks,
>  > >
>  > >           -Mike
>  > >
>  > >
>  > >> Subject: Re: [type-annos-observers] Comments on the Nov 7
> specification
>  > >> From: Eric Bruneton <ebruneton at free.fr>
>  > >> To: type-annotations-spec-comments at openjdk.java.net
>  > >> Date: Sat, 24 Nov 2012 17:28:47 +0100
>  > >>
>  > >> 20/11/2012 21:37, Michael Ernst wrote:
>  > >>> Eric Bruneton said:
>  > >>>
>  > >>>>   From an ASM point of view,
>  > >>>> ...
>  > >>>> The important
>  > >>>> point is that all paths should be "from outside to inside"
>  > (e.g. for nested
>  > >>>> types, the path should go from outer to inner, not the other
>  > way around as
>  > >>>> proposed in the Nov 7 specification).
>  > >>>
>  > >>> Eric, I'm willing to make this change, but I would like to be
> able to give
>  > >>> a more specific justification for the design choice.  Can you
> explain the
>  > >>> rationale, or what difference it makes to ASM?  Is the reason
> that the
>  > >>> identifiers appear left-to-right in the class file and you want
> to process
>  > >>> them in that order, or is it something else?
>  > >>
>  > >> Right, it's basically that. For instance, consider the problem of
>  > >> extracting the part of a type signature in the class file format
>  > >> (e.g. Ljava.util.Map<
>  > +Ljava.lang.String;Ljava.util.List<Ljava.lang.Object;>;>;)
>  > >> that corresponds to a given type_path. With 'outside to inside'
> paths, this
>  > >> can be done with a simple recursive function, like
>  > >> extract(signature,path)
>  > >> - if empty path return signature
>  > >> - otherwise parse the first signature element from the left,
>  > check conformity
>  > >>    with first path element, and call recursively with tail of
> signature and
>  > >>    tail of path.
>  > >>
>  > >> With 'inside to outside' paths, you have to parse the three inner
> types in
>  > >> the signature to realize that
>  > >> "inner_path{inner_path{inner_path{empty_path}}}", for instance,
> was in fact
>  > >> the first parsed type (then you either have to save state during
> parsing,
>  > >> or do another parsing pass).
>  > >>
>  > >> I'm not sure I'm clear, but I hope you get the idea.
>  > >>
>  > >> Eric
>  >

From mernst at cs.washington.edu  Fri Nov 30 11:59:58 2012
From: mernst at cs.washington.edu (Michael Ernst)
Date: Fri, 30 Nov 2012 11:59:58 -0800 (PST)
Subject: [type-annos-observers] Comments on the Nov 7 specification
In-Reply-To: <50B9070A.2030900@oracle.com>
References: <50B50357.5030101@oracle.com>
	<OFF8A28462.9DF8AB90-ON65257AC6.00202F09-65257AC6.002156F4@in.ibm.com>
	<50B9070A.2030900@oracle.com>
Message-ID: <20121130.115958.1067255438623534778.mernst@cs.washington.edu>

> Srikanth, thanks for this information.

Agreed.  Thanks, Srikanth, for your view!

> Mike, here is my view: I think nested types should be represented "left to
> right", so that @A, @B, and @C in:
>
>   @A Outer. @B Middle. @C Inner
>
> are located with these type_path_entry arrays:
>
>   @A: -
>   @B: 1(0)
>   @C: 1(0), 1(0)
>
> I recognize this is not congruent with javac's AST, but I think it is the
> right all-round representation.

OK.  This choice is fine with me.  We need to make a choice one way or the
other, and there are advantages to each with neither clearly dominating the
other.  So, left-to-right it is.

Thanks!

		    -Mike