From srikanth_sankaran at in.ibm.com  Mon Oct  1 19:54:12 2012
From: srikanth_sankaran at in.ibm.com (Srikanth S Adayapalam)
Date: Tue, 2 Oct 2012 08:24:12 +0530
Subject: [type-annos-observers] Classfile format changes for more
	efficient processing
In-Reply-To: <20120921.031537.857440125198746700.mernst@cs.washington.edu>
References: <50516CF6.6050400@free.fr>
	<20120921.031537.857440125198746700.mernst@cs.washington.edu>
Message-ID: <OF311F1254.9A87D3F8-ON65257A8B.000F1F4A-65257A8B.000FFA4F@in.ibm.com>

> From: Michael Ernst <mernst at cs.washington.edu>
> Subject: Re: Classfile format changes for more efficient processing
> Sent by: type-annotations-spec-experts-bounces at openjdk.java.net

> Eric Bruneton suggests some classfile format changes that will make it
more
> efficient to process (e.g., read and write) class files.  See below for
his
> full message.  I plan to accept all of these suggestions.

Hello EG,

Two topics:

(1) There has been a flurry of mails about various proposals being
accepted.
Is there a refresh of the spec planned anytime soon ? Even an informal
draft
would be good enough for me.

(2) Could the spec leads coordinate with the lambda group so that TYPE_USE
is available as a target in the lambda branch ? At the moment it is not and
it is making life complicated for us alternating between 308 & 335 work.
Per
my understanding this is the only change to JRE to support 308 - Is this
correct ? Are there any logistic issues in promoting this change alone to
335 branch that I am naively ignoring ?

Thanks!
Srikanth.


From alex.buckley at oracle.com  Tue Oct  2 07:04:56 2012
From: alex.buckley at oracle.com (Alex Buckley)
Date: Tue, 02 Oct 2012 07:04:56 -0700
Subject: [type-annos-observers] Classfile format changes for more
	efficient processing
In-Reply-To: <OF311F1254.9A87D3F8-ON65257A8B.000F1F4A-65257A8B.000FFA4F@in.ibm.com>
References: <50516CF6.6050400@free.fr>
	<20120921.031537.857440125198746700.mernst@cs.washington.edu>
	<OF311F1254.9A87D3F8-ON65257A8B.000F1F4A-65257A8B.000FFA4F@in.ibm.com>
Message-ID: <506AF488.20703@oracle.com>

On 10/1/2012 7:54 PM, Srikanth S Adayapalam wrote:
> (1) There has been a flurry of mails about various proposals being
> accepted. Is there a refresh of the spec planned anytime soon ? Even
> an informal draft would be good enough for me.

I will leave this to Mike.

> (2) Could the spec leads coordinate with the lambda group so that
> TYPE_USE is available as a target in the lambda branch ? At the
> moment it is not and it is making life complicated for us alternating
> between 308 & 335 work. Per my understanding this is the only change
> to JRE to support 308 - Is this correct ? Are there any logistic
> issues in promoting this change alone to 335 branch that I am naively
> ignoring ?

I think you're looking for a JDK8 binary which supports lambda 
expressions in javac and the Runtime[In]VisibleTypeAnnotations attribute 
in ClassFiles.

This will happen in time. The OpenJDK Lambda and Type Annotations 
projects have their own forests which we don't intend to sync with each 
other directly. Lambda's forest is changing rapidly, whereas Type 
Annotations' forest is stable enough to undergo code review for a push 
into the JDK8 forest. (Specifically, type-annotations/type-annotations 
-> jdk8/tl -> jdk8/jdk8.) I will try to find out when Lambda expects to 
push into JDK8. Once both projects have pushed into JDK8, binaries will 
follow automatically.

Alex

From srikanth_sankaran at in.ibm.com  Mon Oct 22 04:37:08 2012
From: srikanth_sankaran at in.ibm.com (Srikanth S Adayapalam)
Date: Mon, 22 Oct 2012 17:07:08 +0530
Subject: [type-annos-observers] [jsr-308-eg] Fw: Syntax for type
	annotations on fully-qualified	types
In-Reply-To: <20120921.031537.857440125198746700.mernst@cs.washington.edu>
References: <50516CF6.6050400@free.fr>
	<20120921.031537.857440125198746700.mernst@cs.washington.edu>
Message-ID: <OF7B42079C.37776EF4-ON65257A9F.003CEDD4-65257A9F.003FE1C6@in.ibm.com>

Hello EG,

	We have come a long way in the Eclipse Compiler & IDE implementation
of JSR308 and
with a much better appreciation of the issues involved in implementation,
would like to revive
this topic which came up for discussion several months ago:

> From: Michael Ernst <mernst at cs.washington.edu>
> To: jsr-308-eg <jsr-308-eg at jcp.org>
> Date: 31-01-12 04:42 AM
> Subject: [jsr-308-eg] Fw: Syntax for type annotations on fully-qualified
types
> Sent by: jsr-308-eg-bounces at jcp.org

[...]

> I'd like to get your feedback on a recent proposal that the syntax of a
> type annotation on a fully-qualified type should be
>   java.lang. @A Object
> rather than
>   @A java.lang.Object
> The specification currently says the latter, but each has its benefits.

[...]

> Arguments for the change to java.lang. at A Object include:
>  * more uniform with respect to nested classes
>  * easier for people to interpret, and possibly easier to implement
>  * allows future extensions such as annotations on packages
>
> Arguments for the current @A java.lang.Object include:
>  * more aesthetically pleasing, at least to some people; does not break
up
>    the unit "java.lang.Object"; unlike the "OuterClass" type prefix, the
>    "java.lang." package prefix feels like a part of the type
>  * the change primarily improves the syntax for annotations on
fully-qualified
>    nested types.  Maybe those do not come up that often in practice, and
>    maybe the change would make the syntax worse in the common case.
>
> Thoughts?

And Doug Lea responded with:

> From: Doug Lea <dl at cs.oswego.edu>
> To: jsr-308-eg at jcp.org
> Date: 31-01-12 05:33 AM
> Subject: Re: [jsr-308-eg] Fw: Syntax for type annotations on
fully-qualified types
> Sent by: jsr-308-eg-bounces at jcp.org

[...]

> > Arguments for the change to java.lang. at A Object include:
> >   * more uniform with respect to nested classes
> >   * easier for people to interpret, and possibly easier to implement
> >   * allows future extensions such as annotations on packages
>
> This last point seems like the best reason to change syntax.
> Although I suppose some paren rules could be introduced
> to cover (@A java).lang.Object and the like?

[...]

> Also,  the current scheme seems more in keeping with rules for
> qualifiers and cast expressions across dots for method calls.
> As in:
>    (long)aString.length()
> not
>    aString.(long)length();

And Alex Buckley further responded with:

> From: Alex Buckley <alex.buckley at oracle.com>
> To: jsr-308-eg at jcp.org
> Date: 31-01-12 07:56 AM
> Subject: Re: [jsr-308-eg] Fw: Syntax for type annotations on
fully-qualified types
> Sent by: jsr-308-eg-bounces at jcp.org
>
> Hi Mike,
>
> In my view, the uniformity of
>
>    p1.p2. at A C1
>
> with
>
>    p1.p2.C1. at A C2
>
> is not worth much because I don't think nested type names are usually
> qualified in the first place.
> That is, I expect most utterances of a nested type's name are made in
> either the scope of the nested type's declaration or the scope of an
> import declaration, so use a simple type name. We offer a mechanism for
> annotating a nested type name should it be qualified (C1. at A C2 or
> p1.p2.C1. at A C2) but it's somewhat secondary in everyday use.
>
> I think it's quite reasonable to say that an annotation before a
> qualified type name applies to the top-level type named therein
> (p1.p2.C1) and not to nested types of any depth (i.e. not to the type
> p1.p2.C1.C2 or p1.p2.C1.C2.C3 or p1.p2.C1.C2.C3.C4, etc).
>
> Let's talk about annotations on packages:
>
> - First, is Java SE going to support annotating a specific use of a
> package name (as opposed to a package declaration) in the next 10 years?
> Probably not.
>
> - Second, even if a need was identified, I would observe that any
> proposition made about a package name at a use-site could be rolled up
> into a proposition on a top-level type name at the same use-site, i.e.
> rather than "@A java.lang. at B Object" to represent the A-ness of the
> java.lang package and the B-ness of its Object type, write "@AandB
> java.lang.Object" where the annotation applies to the top-level type and
> let the checker figure out that the annotation proposes something about
> the package too.
>
> (Yes, this paragraph could be applied against nested types in general,
> or against the ability to annotate nested type names distinctly from
> top-level type names. But package names are already second-order in
> mainline code, so worrying about how to annotate them in a potential
> future is third-order at best.)
>
> - Third, annotations on expressions/statements (more plausible than on
> package names) will face the problem of grouping alluded to by Doug -
> (@A java).lang.Object - but 1000 times worse. So let's cross that bridge
> when we come to it, and perhaps apply it to package names if the need is
> there.
>
> Bottom line, I'm not too concerned about qualified nested type names or
> about annotating package names, so I think the current 308 spec is fine.

In the current scheme of things, the component of the qualified name that
gets
annotated cannot be determined purely by parsing the program and symbol and
type resolution is mandatory to ascertain that.

Unlike other programming languages, Java has always strived to be precise
and unambiguous. It would be better to keep grammatical concepts in the
grammar and not defer them to a second, context-dependent compiler phase.
Moreover, this is the only place where annotations don't appear directly
in front of the type. The same arguments as given for annotations on
array types (2.2.1) also apply here.

Furthermore, the current spec precludes further language enhancements.
At one time, we may want to add annotations to package references, and
this is not easily possible any more if "@Annot java.util.List" cannot
mean that "java" or "java.util" is annotated.

Of course, this last point has been already discussed and (a) a plausible
work around has already been identified (@Annot java) and (b) is tagged
as an unlikely scenario in the next 10 years - and argued as let us cross
the bridge when we get to it.

Looking back at the arguments, I see only one valid argument (the others
are for why we can live with the present syntax as opposed to is strengths)
for retaining the present syntax : that it could be "more aesthetically
pleasing, at least to some people; does not break up the unit
"java.lang.Object"

However if we agree that in real terms this is not an issue as we expect
imports to be in place that argument also loses potency.

The particular implementation issue we are facing is that, there are
various
AST API clients of Eclipse that could ask for an AST without symbol and
type resolution - i.e the pure output of the parser without further
processing/decorations. We would prefer to be able to discover the
component of the qualified name that is annotated without symbol/type
resolution and this is not possible today with the present syntax.

This has the potential to make client code greatly complicated in that
they need to be prepared to expect to annotations on non-type nodes and
do the "right thing."

In the java.util. at Marker Object scheme, this problems goes away completely
as the presence of type annotations signals that the following component
is a type and only those clients that need to something with the type
nodes need to react.

Comments ?

Srikanth.


From alex.buckley at oracle.com  Wed Oct 24 16:11:13 2012
From: alex.buckley at oracle.com (Alex Buckley)
Date: Wed, 24 Oct 2012 16:11:13 -0700
Subject: [type-annos-observers] [jsr-308-eg] Fw: Syntax for type
	annotations on fully-qualified	types
In-Reply-To: <OF7B42079C.37776EF4-ON65257A9F.003CEDD4-65257A9F.003FE1C6@in.ibm.com>
References: <50516CF6.6050400@free.fr>
	<20120921.031537.857440125198746700.mernst@cs.washington.edu>
	<OF7B42079C.37776EF4-ON65257A9F.003CEDD4-65257A9F.003FE1C6@in.ibm.com>
Message-ID: <50887591.5030806@oracle.com>

Hi Srikanth,

I respect your concern that it's a bad idea to separate a) the syntactic 
location of an annotation from b) the semantic entity to which it 
applies. As you say, for array types we kept an annotation "close" to 
the exact type being annotated. In fact, I think your proposal works 
especially well for array types, because this:

   p1.p2. at Foo C @Bar []  x,y;

is more readable to my eye than:

   @Foo p1.p2.C @Bar []  x,y;

The JSR 308 spec currently notes that "For a nested type, the type 
annotation appears before the type's simple name." Your proposal allows 
"For a nested type" to be removed. On balance, I can agree with your 
proposal.

(I still don't think package names will be annotated anytime soon :-) )

Alex

On 10/22/2012 4:37 AM, Srikanth S Adayapalam wrote:
> Hello EG,
>
> 	We have come a long way in the Eclipse Compiler & IDE implementation
> of JSR308 and
> with a much better appreciation of the issues involved in implementation,
> would like to revive
> this topic which came up for discussion several months ago:
>
>> From: Michael Ernst <mernst at cs.washington.edu>
>> To: jsr-308-eg <jsr-308-eg at jcp.org>
>> Date: 31-01-12 04:42 AM
>> Subject: [jsr-308-eg] Fw: Syntax for type annotations on fully-qualified
> types
>> Sent by: jsr-308-eg-bounces at jcp.org
>
> [...]
>
>> I'd like to get your feedback on a recent proposal that the syntax of a
>> type annotation on a fully-qualified type should be
>>    java.lang. @A Object
>> rather than
>>    @A java.lang.Object
>> The specification currently says the latter, but each has its benefits.
>
> [...]
>
>> Arguments for the change to java.lang. at A Object include:
>>   * more uniform with respect to nested classes
>>   * easier for people to interpret, and possibly easier to implement
>>   * allows future extensions such as annotations on packages
>>
>> Arguments for the current @A java.lang.Object include:
>>   * more aesthetically pleasing, at least to some people; does not break
> up
>>     the unit "java.lang.Object"; unlike the "OuterClass" type prefix, the
>>     "java.lang." package prefix feels like a part of the type
>>   * the change primarily improves the syntax for annotations on
> fully-qualified
>>     nested types.  Maybe those do not come up that often in practice, and
>>     maybe the change would make the syntax worse in the common case.
>>
>> Thoughts?
>
> And Doug Lea responded with:
>
>> From: Doug Lea <dl at cs.oswego.edu>
>> To: jsr-308-eg at jcp.org
>> Date: 31-01-12 05:33 AM
>> Subject: Re: [jsr-308-eg] Fw: Syntax for type annotations on
> fully-qualified types
>> Sent by: jsr-308-eg-bounces at jcp.org
>
> [...]
>
>>> Arguments for the change to java.lang. at A Object include:
>>>    * more uniform with respect to nested classes
>>>    * easier for people to interpret, and possibly easier to implement
>>>    * allows future extensions such as annotations on packages
>>
>> This last point seems like the best reason to change syntax.
>> Although I suppose some paren rules could be introduced
>> to cover (@A java).lang.Object and the like?
>
> [...]
>
>> Also,  the current scheme seems more in keeping with rules for
>> qualifiers and cast expressions across dots for method calls.
>> As in:
>>     (long)aString.length()
>> not
>>     aString.(long)length();
>
> And Alex Buckley further responded with:
>
>> From: Alex Buckley <alex.buckley at oracle.com>
>> To: jsr-308-eg at jcp.org
>> Date: 31-01-12 07:56 AM
>> Subject: Re: [jsr-308-eg] Fw: Syntax for type annotations on
> fully-qualified types
>> Sent by: jsr-308-eg-bounces at jcp.org
>>
>> Hi Mike,
>>
>> In my view, the uniformity of
>>
>>     p1.p2. at A C1
>>
>> with
>>
>>     p1.p2.C1. at A C2
>>
>> is not worth much because I don't think nested type names are usually
>> qualified in the first place.
>> That is, I expect most utterances of a nested type's name are made in
>> either the scope of the nested type's declaration or the scope of an
>> import declaration, so use a simple type name. We offer a mechanism for
>> annotating a nested type name should it be qualified (C1. at A C2 or
>> p1.p2.C1. at A C2) but it's somewhat secondary in everyday use.
>>
>> I think it's quite reasonable to say that an annotation before a
>> qualified type name applies to the top-level type named therein
>> (p1.p2.C1) and not to nested types of any depth (i.e. not to the type
>> p1.p2.C1.C2 or p1.p2.C1.C2.C3 or p1.p2.C1.C2.C3.C4, etc).
>>
>> Let's talk about annotations on packages:
>>
>> - First, is Java SE going to support annotating a specific use of a
>> package name (as opposed to a package declaration) in the next 10 years?
>> Probably not.
>>
>> - Second, even if a need was identified, I would observe that any
>> proposition made about a package name at a use-site could be rolled up
>> into a proposition on a top-level type name at the same use-site, i.e.
>> rather than "@A java.lang. at B Object" to represent the A-ness of the
>> java.lang package and the B-ness of its Object type, write "@AandB
>> java.lang.Object" where the annotation applies to the top-level type and
>> let the checker figure out that the annotation proposes something about
>> the package too.
>>
>> (Yes, this paragraph could be applied against nested types in general,
>> or against the ability to annotate nested type names distinctly from
>> top-level type names. But package names are already second-order in
>> mainline code, so worrying about how to annotate them in a potential
>> future is third-order at best.)
>>
>> - Third, annotations on expressions/statements (more plausible than on
>> package names) will face the problem of grouping alluded to by Doug -
>> (@A java).lang.Object - but 1000 times worse. So let's cross that bridge
>> when we come to it, and perhaps apply it to package names if the need is
>> there.
>>
>> Bottom line, I'm not too concerned about qualified nested type names or
>> about annotating package names, so I think the current 308 spec is fine.
>
> In the current scheme of things, the component of the qualified name that
> gets
> annotated cannot be determined purely by parsing the program and symbol and
> type resolution is mandatory to ascertain that.
>
> Unlike other programming languages, Java has always strived to be precise
> and unambiguous. It would be better to keep grammatical concepts in the
> grammar and not defer them to a second, context-dependent compiler phase.
> Moreover, this is the only place where annotations don't appear directly
> in front of the type. The same arguments as given for annotations on
> array types (2.2.1) also apply here.
>
> Furthermore, the current spec precludes further language enhancements.
> At one time, we may want to add annotations to package references, and
> this is not easily possible any more if "@Annot java.util.List" cannot
> mean that "java" or "java.util" is annotated.
>
> Of course, this last point has been already discussed and (a) a plausible
> work around has already been identified (@Annot java) and (b) is tagged
> as an unlikely scenario in the next 10 years - and argued as let us cross
> the bridge when we get to it.
>
> Looking back at the arguments, I see only one valid argument (the others
> are for why we can live with the present syntax as opposed to is strengths)
> for retaining the present syntax : that it could be "more aesthetically
> pleasing, at least to some people; does not break up the unit
> "java.lang.Object"
>
> However if we agree that in real terms this is not an issue as we expect
> imports to be in place that argument also loses potency.
>
> The particular implementation issue we are facing is that, there are
> various
> AST API clients of Eclipse that could ask for an AST without symbol and
> type resolution - i.e the pure output of the parser without further
> processing/decorations. We would prefer to be able to discover the
> component of the qualified name that is annotated without symbol/type
> resolution and this is not possible today with the present syntax.
>
> This has the potential to make client code greatly complicated in that
> they need to be prepared to expect to annotations on non-type nodes and
> do the "right thing."
>
> In the java.util. at Marker Object scheme, this problems goes away completely
> as the presence of type annotations signals that the following component
> is a type and only those clients that need to something with the type
> nodes need to react.
>
> Comments ?
>
> Srikanth.
>

From srikanth_sankaran at in.ibm.com  Wed Oct 24 23:37:14 2012
From: srikanth_sankaran at in.ibm.com (Srikanth S Adayapalam)
Date: Thu, 25 Oct 2012 12:07:14 +0530
Subject: [type-annos-observers] [jsr-308-eg] Fw: Syntax for type
	annotations on	fully-qualified	types
In-Reply-To: <50887591.5030806@oracle.com>
References: <50516CF6.6050400@free.fr>	<20120921.031537.857440125198746700.mernst@cs.washington.edu>
	<OF7B42079C.37776EF4-ON65257A9F.003CEDD4-65257A9F.003FE1C6@in.ibm.com>
	<50887591.5030806@oracle.com>
Message-ID: <OFB386AE04.653EE1DD-ON65257AA2.0024343B-65257AA2.00246BE4@in.ibm.com>

> From: Alex Buckley <alex.buckley at oracle.com>
> Subject: Re: [jsr-308-eg] Fw: Syntax for type annotations on
fully-qualified types
> Sent by: type-annotations-spec-experts-bounces at openjdk.java.net
>
> Hi Srikanth,

> The JSR 308 spec currently notes that "For a nested type, the type
> annotation appears before the type's simple name." Your proposal allows
> "For a nested type" to be removed. On balance, I can agree with your
> proposal.

Thanks, Also 2.1 (1) states:
"A type annotation appears before the type, as in @NonNull String or
@NonNull java.lang.String. A type annotation
appears before the package name, if any. Here are examples:"

Mike, please let us know of your thoughts.

Srikanth.


From mernst at cs.washington.edu  Thu Oct 25 09:50:12 2012
From: mernst at cs.washington.edu (Michael Ernst)
Date: Thu, 25 Oct 2012 09:50:12 -0700 (PDT)
Subject: [type-annos-observers] [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: <20121025.095012.1655271957449422068.mernst@cs.washington.edu>

Srikanth and Alex,

I'm traveling now but will get back to you at the beginning of next week.
Thanks for your patience!

		    -Mike