From srikanth_sankaran at in.ibm.com Sun Oct 6 23:46:45 2013 From: srikanth_sankaran at in.ibm.com (Srikanth S Adayapalam) Date: Mon, 7 Oct 2013 12:16:45 +0530 Subject: error: enclosing static nested class cannot be annotated ?? Message-ID: Hello ! I see that 8b108 rejects the following code. I am trying to trace this behavior back to the spec - with not clear cut success. Could you help clarify the behavior ? Thanks! Srikanth. // -- import java.lang.annotation.ElementType; import java.lang.annotation.Target; @Target(ElementType.TYPE_USE) @interface Illegal { } class Y { static class YY { class Z { Z() {} } } } class X { Y.YY.Z foo2() { Y. at Illegal YY.Z z = null; // illegal ??? return z; } } From wdietl at gmail.com Mon Oct 7 08:44:26 2013 From: wdietl at gmail.com (Werner Dietl) Date: Mon, 7 Oct 2013 11:44:26 -0400 Subject: [type-annos-observers] error: enclosing static nested class cannot be annotated ?? In-Reply-To: References: Message-ID: Hi Srikanth, I pushed an update to checking of these rules yesterday. Your attached example now passes, as you expected. If you instead try: @Illegal Y.YY.Z z2 = null; you now get: error: scoping construct cannot be annotated with type-use annotation: @Illegal @Illegal Y.YY.Z z2 = null; I think this corresponds to what a recent update to the JSR 308 spec prescribes. Comments welcome. cu, WMD. On Mon, Oct 7, 2013 at 2:46 AM, Srikanth S Adayapalam wrote: > Hello ! > > > I see that 8b108 rejects the following code. > I am trying to trace this behavior back to the > spec - with not clear cut success. Could you > help clarify the behavior ? > > Thanks! > Srikanth. > > > > // -- > import java.lang.annotation.ElementType; > import java.lang.annotation.Target; > > @Target(ElementType.TYPE_USE) > @interface Illegal { > } > class Y { > static class YY { > class Z { > Z() {} > } > } > } > class X { > Y.YY.Z foo2() { > Y. at Illegal YY.Z z = null; // illegal ??? > return z; > } > } -- http://www.google.com/profiles/wdietl From alex.buckley at oracle.com Mon Oct 7 17:33:29 2013 From: alex.buckley at oracle.com (Alex Buckley) Date: Mon, 07 Oct 2013 17:33:29 -0700 Subject: [type-annos-observers] error: enclosing static nested class cannot be annotated ?? In-Reply-To: References: Message-ID: <525352D9.2080102@oracle.com> Werner, You're saying that an annotation at the outermost level of the type (@Illegal Y.YY.Z) is illegal if the type (Y.YY.Z) has any sub-part (YY) which is a static member type. But in CantAnnotateStaticClass2, with basically the same class nest: class Top { static class Outer { class Inner {} static class SInner {} interface IInner {} } @TB Outer. @TC Inner f1c; @TB Outer. @TC SInner f2c; // err @TB Outer. @TC IInner f3c; // err } you're allowing @TB at the outermost level of f1c's type, even though the type Outer.Inner involves a static member type (Outer is static in Top). Why no error? Can you please try to write a few bullet points for what you've made javac do? Separately, I can understand the error for @TB at the outermost level of f2c's type and f3c's type, since Outer is being used as a scoping mechanism to access a static member. That was laid out in Mike's spec: @Illegal Outer.StaticNestedClass // illegal! @Illegal Outer.staticField // illegal! Alex On 10/7/2013 8:44 AM, Werner Dietl wrote: > Hi Srikanth, > > I pushed an update to checking of these rules yesterday. > Your attached example now passes, as you expected. > If you instead try: > > @Illegal Y.YY.Z z2 = null; > > you now get: > > error: scoping construct cannot be annotated with type-use annotation: @Illegal > @Illegal Y.YY.Z z2 = null; > > I think this corresponds to what a recent update to the JSR 308 spec prescribes. > > Comments welcome. > cu, WMD. > > > > On Mon, Oct 7, 2013 at 2:46 AM, Srikanth S Adayapalam > wrote: >> Hello ! >> >> >> I see that 8b108 rejects the following code. >> I am trying to trace this behavior back to the >> spec - with not clear cut success. Could you >> help clarify the behavior ? >> >> Thanks! >> Srikanth. >> >> >> >> // -- >> import java.lang.annotation.ElementType; >> import java.lang.annotation.Target; >> >> @Target(ElementType.TYPE_USE) >> @interface Illegal { >> } >> class Y { >> static class YY { >> class Z { >> Z() {} >> } >> } >> } >> class X { >> Y.YY.Z foo2() { >> Y. at Illegal YY.Z z = null; // illegal ??? >> return z; >> } >> } > > > From wdietl at gmail.com Mon Oct 7 19:30:11 2013 From: wdietl at gmail.com (Werner Dietl) Date: Mon, 7 Oct 2013 22:30:11 -0400 Subject: [type-annos-observers] error: enclosing static nested class cannot be annotated ?? In-Reply-To: <525352D9.2080102@oracle.com> References: <525352D9.2080102@oracle.com> Message-ID: Hi Alex, thanks for your comments. > You're saying that an annotation at the outermost level of the type > (@Illegal Y.YY.Z) is illegal if the type (Y.YY.Z) has any sub-part (YY) > which is a static member type. > > But in CantAnnotateStaticClass2, with basically the same class nest: > > class Top { > static class Outer { > class Inner {} > static class SInner {} > interface IInner {} > } > > @TB Outer. @TC Inner f1c; > @TB Outer. @TC SInner f2c; // err > @TB Outer. @TC IInner f3c; // err > } > > you're allowing @TB at the outermost level of f1c's type, even though the > type Outer.Inner involves a static member type (Outer is static in Top). > > Why no error? Can you please try to write a few bullet points for what > you've made javac do? I think there is a difference between Srikanth's example and the test case. The basic intuition I have is that if in the inner class I can write "Outer.this", then Outer is not only for scoping - that is, I can use a type annotation on it. Let's take Srikanth's example and add two fields: class Y { static class YY { Object o = Y.this; // illegal class Z { Object o = YY.this; // ok Z() {} } } } If I have "Y.YY", Y is the outer type and YY is the nested type. In YY, writing "Y.this" is forbidden - there is no enclosing instance. Therefore "@TA Y. YY" should be forbidden, because it applies a type annotation to a construct only used for scoping. On the other hand, in YY.Z, we can allow a type annotation on YY: writing YY.this is legal, that is, there is an enclosing instance. I applied the same rule in the test case that you quote: class Top { static class Outer { class Inner {} static class SInner {} interface IInner {} } @TB Outer. @TC Inner f1c; @TB Outer. @TC SInner f2c; // err @TB Outer. @TC IInner f3c; // err } Looking at f1c, In class Inner I can access Outer.this. Therefore I can annotate Outer. Neither SInner nor IInner have an outer instance and therefore @TB has to be forbidden. Put differently, it makes a difference whether the static class is on the left or right of the selection. It is OK if the left class is static; it is not OK for the right type to be static. I think with a slight variation of the rule, one can argue whether "new Outer.Inner()" should be legal or not. Does this make sense? If not, what is the correct interpretation? > Separately, I can understand the error for @TB at the outermost level of > f2c's type and f3c's type, since Outer is being used as a scoping mechanism > to access a static member. That was laid out in Mike's spec: > > @Illegal Outer.StaticNestedClass // illegal! > @Illegal Outer.staticField // illegal! I agree. cu, WMD. > On 10/7/2013 8:44 AM, Werner Dietl wrote: >> >> Hi Srikanth, >> >> I pushed an update to checking of these rules yesterday. >> Your attached example now passes, as you expected. >> If you instead try: >> >> @Illegal Y.YY.Z z2 = null; >> >> you now get: >> >> error: scoping construct cannot be annotated with type-use annotation: >> @Illegal >> @Illegal Y.YY.Z z2 = null; >> >> I think this corresponds to what a recent update to the JSR 308 spec >> prescribes. >> >> Comments welcome. >> cu, WMD. >> >> >> >> On Mon, Oct 7, 2013 at 2:46 AM, Srikanth S Adayapalam >> wrote: >>> >>> Hello ! >>> >>> >>> I see that 8b108 rejects the following code. >>> I am trying to trace this behavior back to the >>> spec - with not clear cut success. Could you >>> help clarify the behavior ? >>> >>> Thanks! >>> Srikanth. >>> >>> >>> >>> // -- >>> import java.lang.annotation.ElementType; >>> import java.lang.annotation.Target; >>> >>> @Target(ElementType.TYPE_USE) >>> @interface Illegal { >>> } >>> class Y { >>> static class YY { >>> class Z { >>> Z() {} >>> } >>> } >>> } >>> class X { >>> Y.YY.Z foo2() { >>> Y. at Illegal YY.Z z = null; // illegal ??? >>> return z; >>> } >>> } >> >> >> >> > -- http://www.google.com/profiles/wdietl From srikanth_sankaran at in.ibm.com Mon Oct 7 20:12:04 2013 From: srikanth_sankaran at in.ibm.com (Srikanth S Adayapalam) Date: Tue, 8 Oct 2013 08:42:04 +0530 Subject: [type-annos-observers] error: enclosing static nested class cannot be annotated ?? In-Reply-To: References: <525352D9.2080102@oracle.com> Message-ID: I'll let this discussion take its course to see where it leads. In the meantime here are some other examples that show the reference compiler (8b108) behaving inconsistently. This is admittedly not the place to report RI issues, but to the extent they are pertinent to the discussion at hand, they should be useful: Thanks, Srikanth 1. I would expect two errors here, but get only one: import java.lang.annotation.ElementType; import java.lang.annotation.Target; @Target(ElementType.TYPE_USE) @interface Illegal { } class Y { static class Z { Z() {} } } class X { Y.Z foo() { @Illegal Y.Z z = null; return z; } Y.Z bar() { Y.Z z = (@Illegal Y.Z)null; // No error here ?? return z; } } 2. I would not expect an error at annotation site of @LegalTypeUseParam: I would expect that the TYPE_USE target to be silently discarded and the PARAMETER target to be honored. This is by intuition, not sure if the spec sanctions such. import java.lang.annotation.ElementType; import java.lang.annotation.Target; @Target(ElementType.TYPE_USE) @interface IllegalTypeUse { } @Target({ElementType.TYPE_USE, ElementType.PARAMETER}) @interface LegalTypeUseParam { } @Target(ElementType.PARAMETER) @interface LegalParam { } class Y { static class Z { Z() {} } } class X { Y.Z foo(@LegalParam Y.Z z) { //Legal return z; } Y.Z foo2(@LegalTypeUseParam Y.Z z) { //Legal return z; } Y.Z foo3(@IllegalTypeUse @LegalParam Y.Z z) { //Illegal return z; } } From srikanth_sankaran at in.ibm.com Mon Oct 7 20:22:49 2013 From: srikanth_sankaran at in.ibm.com (Srikanth S Adayapalam) Date: Tue, 8 Oct 2013 08:52:49 +0530 Subject: What annotations would I expect to see on the TypeMirror materialized from a TypeElement ? In-Reply-To: References: <525352D9.2080102@oracle.com> Message-ID: Hello, Thanks in advance for your clarification. @TypeUseAnnotation public class X { } Experiments with 8b108 show that (typeElement.asType()). getAnnotationMirrors() return nothing. Is this warranted ? Srikanth From wdietl at gmail.com Mon Oct 7 20:27:41 2013 From: wdietl at gmail.com (Werner Dietl) Date: Mon, 07 Oct 2013 23:27:41 -0400 Subject: [type-annos-observers] error: enclosing static nested class cannot be annotated ?? In-Reply-To: References: <525352D9.2080102@oracle.com> Message-ID: <52537BAD.1080600@gmail.com> Hi Srikanth, thanks for the additional test cases! On 10/07/2013 11:12 PM, Srikanth S Adayapalam wrote: > I'll let this discussion take its course to see where it leads. In the > meantime here are > some other examples that show the reference compiler (8b108) behaving > inconsistently. > This is admittedly not the place to report RI issues, but to the extent > they are pertinent > to the discussion at hand, they should be useful: > Thanks, > Srikanth > > 1. I would expect two errors here, but get only one: > > import java.lang.annotation.ElementType; > import java.lang.annotation.Target; > > @Target(ElementType.TYPE_USE) > @interface Illegal { > } > class Y { > static class Z { > Z() {} > } > } > class X { > Y.Z foo() { > @Illegal Y.Z z = null; > return z; > } > Y.Z bar() { > Y.Z z = (@Illegal Y.Z)null; // No > error here ?? > return z; > } > } This is fixed in the type-annotations version. I get two errors: Srikanth1.java:14: error: scoping construct cannot be annotated with type-use annotation: @Illegal @Illegal Y.Z z = null; ^ Srikanth1.java:18: error: scoping construct cannot be annotated with type-use annotation: @Illegal Y.Z z = (@Illegal Y.Z)null; // No error here ?? ^ 2 errors > 2. I would not expect an error at annotation site of @LegalTypeUseParam: > I would expect > that the TYPE_USE target to be silently discarded and the PARAMETER > target to be honored. > This is by intuition, not sure if the spec sanctions such. > > import java.lang.annotation.ElementType; > import java.lang.annotation.Target; > > @Target(ElementType.TYPE_USE) > @interface IllegalTypeUse { > } > @Target({ElementType.TYPE_USE, ElementType.PARAMETER}) > @interface LegalTypeUseParam { > } > @Target(ElementType.PARAMETER) > @interface LegalParam { > } > class Y { > static class Z { > Z() {} > } > } > class X { > Y.Z foo(@LegalParam Y.Z z) { //Legal > return z; > } > Y.Z foo2(@LegalTypeUseParam Y.Z z) { //Legal > return z; > } > Y.Z foo3(@IllegalTypeUse @LegalParam Y.Z z) { //Illegal > return z; > } > } With the type-annotations version I get one error: Srikanth2.java:25: error: scoping construct cannot be annotated with type-use annotation: @IllegalTypeUse Y.Z foo3(@IllegalTypeUse @LegalParam Y.Z z) { //Illegal ^ 1 error I hope this updated behavior is what you expect. cu, WMD. From srikanth_sankaran at in.ibm.com Mon Oct 7 20:31:01 2013 From: srikanth_sankaran at in.ibm.com (Srikanth S Adayapalam) Date: Tue, 8 Oct 2013 09:01:01 +0530 Subject: [type-annos-observers] error: enclosing static nested class cannot be annotated ?? In-Reply-To: <52537BAD.1080600@gmail.com> References: <525352D9.2080102@oracle.com> <52537BAD.1080600@gmail.com> Message-ID: > From: Werner Dietl > Subject: Re: [type-annos-observers] error: enclosing static nested > class cannot be annotated ?? [...] > This is fixed in the type-annotations version. I get two errors: > I hope this updated behavior is what you expect. It is, thanks, but I am confused by the reference to type-annotations version. A while ago, we observed that 8bx stream downloads have both 335 and 308 support in them and concluded that the branches are merged and we can use one download as the RI for both JSRs - so this is not true ? Srikanth. From srikanth_sankaran at in.ibm.com Mon Oct 7 20:35:53 2013 From: srikanth_sankaran at in.ibm.com (Srikanth S Adayapalam) Date: Tue, 8 Oct 2013 09:05:53 +0530 Subject: What annotations would I expect to see on the TypeMirror materialized from a TypeElement ? In-Reply-To: References: <525352D9.2080102@oracle.com> Message-ID: > From: Srikanth S Adayapalam/India/IBM at IBMIN > Sent by: type-annotations-spec-experts-bounces at openjdk.java.net > > Hello, > > Thanks in advance for your clarification. > > @TypeUseAnnotation > public class X { > > } > > Experiments with 8b108 show that (typeElement.asType()). > getAnnotationMirrors() > return nothing. Is this warranted ? I should have added: we like this behavior :) it simplifies somethings in our implementation and imposes a model that from a TypeMirror you get annotations for the type-use site and from an Element you get annotations for a declaration site. Nevertheless checking to make sure this is intended. Thanks! Srikanth From alex.buckley at oracle.com Tue Oct 8 13:59:19 2013 From: alex.buckley at oracle.com (Alex Buckley) Date: Tue, 08 Oct 2013 13:59:19 -0700 Subject: [type-annos-observers] error: enclosing static nested class cannot be annotated ?? In-Reply-To: <52537BAD.1080600@gmail.com> References: <525352D9.2080102@oracle.com> <52537BAD.1080600@gmail.com> Message-ID: <52547227.90901@oracle.com> On 10/7/2013 8:27 PM, Werner Dietl wrote: > On 10/07/2013 11:12 PM, Srikanth S Adayapalam wrote: >> 2. I would not expect an error at annotation site of @LegalTypeUseParam: >> I would expect >> that the TYPE_USE target to be silently discarded and the PARAMETER >> target to be honored. >> Y.Z foo3(@IllegalTypeUse @LegalParam Y.Z z) { //Illegal Srikanth, @LegalTypeUseParam doesn't appear here. The @IllegalTypeUse is illegal as Werner confirmed. If the signature really was "foo3(@LegalTypeUseParam @LegalParam Y.Z z)", then the spec would say that: - Syntactically, @LegalTypeUseParam is parsed as a VariableModifier of the FormalParameter production. - Semantically, @LegalTypeUseParam is deemed to be a modifier for the declaration (because LegalTypeUseParam is applicable in the PARAMETER declaration context) _and_ a decorator for the type of the declared entity (because LegalTypeUseParam is applicable in the type context provided by a formal parameter declaration). - It so happens that the type Y.Z is not annotatable, but no error is due because LegalTypeUseParam is applicable more widely than type contexts. So, @LegalTypeUseParam applies to the formal parameter declaration as usual. (I may have some spec tweaking to do here.) Alex From alex.buckley at oracle.com Tue Oct 8 14:03:50 2013 From: alex.buckley at oracle.com (Alex Buckley) Date: Tue, 08 Oct 2013 14:03:50 -0700 Subject: [type-annos-observers] error: enclosing static nested class cannot be annotated ?? In-Reply-To: References: <525352D9.2080102@oracle.com> <52537BAD.1080600@gmail.com> Message-ID: <52547336.7060101@oracle.com> On 10/7/2013 8:31 PM, Srikanth S Adayapalam wrote: > It is, thanks, but I am confused by the reference to type-annotations > version. A while ago, we observed that 8bx stream downloads have both > 335 and 308 support in them and concluded that the branches are merged > and we can use one download as the RI for both JSRs - so this is not > true ? Werner is a Committer in the Type Annotations project, so he pushed his fixes to the 'type-annotations' forest. The fixes will make their way to the 'tl' forest and eventually to the master 'jdk8' forest which is the source of the builds which you use. I don't recall right now whether the Lambda project is still going through its 'lambda' forest, or straight into 'tl', but anyway you can still use the JDK8 download as your RI. Alex From alex.buckley at oracle.com Tue Oct 8 17:53:36 2013 From: alex.buckley at oracle.com (Alex Buckley) Date: Tue, 08 Oct 2013 17:53:36 -0700 Subject: [type-annos-observers] error: enclosing static nested class cannot be annotated ?? In-Reply-To: References: <525352D9.2080102@oracle.com> Message-ID: <5254A910.2060102@oracle.com> Hi Werner, On 10/7/2013 7:30 PM, Werner Dietl wrote: > Put differently, it makes a difference whether the static class is on > the left or right of the selection. It is OK if the left class is > static; it is not OK for the right type to be static. OK, got it. The trick is to focus very closely on the annotation and the two names immediately following it. The annotation and the two names may be at the "top level" of a type, such as "@Illegal Y.YY.Z", where an error occurs because YY is static in Y. Or the annotation and the type names may appear deep within a type, such as "Y. at Illegal YY.Z", where the annotation is in fact legal because Z is non-static in YY. I will formulate this semantic constraint and a related one as follows: ----- A type annotation is _admissible_ if both of the following hold: - The simple name to which the annotation is closest is classified as a TypeName, not a PackageName. - If the simple name to which the annotation is closest is followed by "." and another TypeName, i.e., the annotation appears as @X T.U, then U denotes an inner class of T. It is a compile-time error if an annotation of type T applies to a type (or any part of a type) in a type context, and T is applicable in type contexts, and the annotation is not admissible. ----- Alex From alex.buckley at oracle.com Tue Oct 8 18:33:16 2013 From: alex.buckley at oracle.com (Alex Buckley) Date: Tue, 08 Oct 2013 18:33:16 -0700 Subject: What annotations would I expect to see on the TypeMirror materialized from a TypeElement ? In-Reply-To: References: <525352D9.2080102@oracle.com> Message-ID: <5254B25C.9080400@oracle.com> // cc'ing Leonid as JCK owns Language Model tests for Type Annotations On 10/7/2013 8:35 PM, Srikanth S Adayapalam wrote: >> Thanks in advance for your clarification. >> >> @TypeUseAnnotation >> public class X { >> } >> >> Experiments with 8b108 show that (typeElement.asType()). >> getAnnotationMirrors() >> return nothing. Is this warranted ? > > I should have added: we like this behavior :) it simplifies > somethings in our implementation and imposes a model that > from a TypeMirror you get annotations for the type-use site > and from an Element you get annotations for a declaration > site. > > Nevertheless checking to make sure this is intended. I think it's a reasonable outcome. Assuming TypeUseAnnotation is meta-annotated with @Target(ElementType.TYPE_USE), the annotation @TypeUseAnnotation applies to the class declaration, and I would expect typeElement.getAnnotationMirrors() to return it. But for typeElement.asType(), you're getting a representation of a particular use of type X - but there isn't really such a use when X is still being declared. I wouldn't expect the TypeMirror to be able to tell you much. In particular, the javadoc for AnnotatedConstruct (which both Element and TypeMirror implement) says "Annotations on an element are on a declaration, whereas annotations on a type are on a specific use of a type name." - and there are no annotation on the "X" which appears after "class". Alex [1] http://mail.openjdk.java.net/pipermail/type-annotations-spec-experts/2013-February/000064.html From srikanth_sankaran at in.ibm.com Mon Oct 14 22:55:36 2013 From: srikanth_sankaran at in.ibm.com (Srikanth S Adayapalam) Date: Tue, 15 Oct 2013 11:25:36 +0530 Subject: RetentionPolicy.CLASS too broad for TYPE_USE annotations ? Message-ID: Dear EG, AFAICT, this issue raised by Markus Keller in the observer's list: http://mail.openjdk.java.net/pipermail/type-annotations-spec-observers/2013-July/000172.html has gone unanswered. This raises concerns about class file bloat and needs attention. If this was indeed discussed and I missed it somehow, appreciate pointers. Thanks! Srikanth From alex.buckley at oracle.com Tue Oct 15 10:58:46 2013 From: alex.buckley at oracle.com (Alex Buckley) Date: Tue, 15 Oct 2013 10:58:46 -0700 Subject: RetentionPolicy.CLASS too broad for TYPE_USE annotations ? In-Reply-To: References: Message-ID: <525D8256.3020306@oracle.com> Markus' mail went unanswered because it was sent to a list that the EG does not generally follow. From the listinfo page for type-annotations-spec-observers: "Members of the JSR 308 Expert Group are not required to follow traffic on this list. Questions for the Expert Group about the design and specification of JSR 308 may be sent to the type-annotations-spec-comments list." Markus suggested that TYPE_USE annotations which appear on types in expressions (e.g. 'instanceof @Foo String') should not be stored in the class file if the annotation's own type was RetentionPolicy.CLASS (or presumably RetentionPolicy.RUNTIME). Markus suggested that expression locations be excluded from RetentionPolicy.CLASS/RUNTIME, then either be given their own RetentionPolicy enum constant or be flagged for class file storage via compiler-specific flags (c.f. -parameters). That's an interesting idea but at this point I'm afraid it's too late to consider. Alex On 10/14/2013 10:55 PM, Srikanth S Adayapalam wrote: > Dear EG, > > AFAICT, this issue raised by Markus Keller in the observer's list: > http://mail.openjdk.java.net/pipermail/type-annotations-spec-observers/2013-July/000172.html > > has gone unanswered. > > This raises concerns about class file bloat and needs attention. > > If this was indeed discussed and I missed it somehow, appreciate pointers. > > Thanks! > Srikanth > From alex.buckley at oracle.com Tue Oct 15 15:57:01 2013 From: alex.buckley at oracle.com (Alex Buckley) Date: Tue, 15 Oct 2013 15:57:01 -0700 Subject: RetentionPolicy.CLASS too broad for TYPE_USE annotations ? In-Reply-To: References: <525D8256.3020306@oracle.com> Message-ID: <525DC83D.4040104@oracle.com> Markus raised some great points on the type-annotations-spec-observers list, in regard to the draft JLS/JVMS updates for 308. On 10/15/2013 1:10 PM, Markus Keller wrote: > Could you please have a look at these? Shouldn't be too late for that. > http://mail.openjdk.java.net/pipermail/type-annotations-spec-observers/2013-August/000179.html 1. The name of a receiver parameter in the draft is allowed to be 'this' or the text of a qualified expression indicating the same class. I raised this issue with the EG on April 10 ("Clarifying the receiver parameter") because the 308 design document gave only an example. Srikanth asked for rationale; I gave it. No-one else commented despite my best efforts to highlight the semi-open thread at later dates. 2. I take your point about the draft grammar. This has been discussed over the years, and my natural tendency towards a simple recursive production ("Type {Annotation} []") is not in fact what was settled on. I will change ArrayType to align with section 2.2 in the 308 design document, where "{Annotation} []" can repeat after a non-array type. I will also clarify the precise type in an array type to which an annotation applies. > http://mail.openjdk.java.net/pipermail/type-annotations-spec-observers/2013-October/000208.html 1. I have corrected the "Where Types Are Used" paragraph to acknowledge primitive types. This is normative but non-testable text, i.e. a sketch, so it doesn't have to mention array types although it could do so as the 308 spec settles in the JLS at a later date. 2. The places where 'void' is mentioned in the 308 design document are: ----- The grammar permits modifiers, declaration annotations, and type annotation to be freely intermixed at any location where all are permitted (such as before a field declaration or a non-void-returning method). @MAnno void myMethod1() { ... } // legal, one method annotation @TAnno void myMethod2() { ... } // illegal @MTAnno void myMethod3() { ... } // legal, one method annotation ----- The clear intent is that 'void', not being a type, cannot be preceded by a TYPE_USE annotation. I will make it a compile-time error if this happens in a method declaration. Alex From alex.buckley at oracle.com Wed Oct 16 11:32:38 2013 From: alex.buckley at oracle.com (Alex Buckley) Date: Wed, 16 Oct 2013 11:32:38 -0700 Subject: Public Review for JSR 308 Message-ID: <525EDBC6.3030101@oracle.com> In line with the Java SE 8 Platform schedule at http://openjdk.java.net/projects/jdk8/spec/, we're planning to submit materials for the Public Review of JSR 308 next Thursday, 10/24. The Public Review will run from 10/31 to 12/02, with approval ballots in the JCP Executive Committee from 12/03 to 12/16. The other SE 8 JSRs are doing the same. In preparation for this milestone, I have updated the draft JLS/JVMS document at http://cr.openjdk.java.net/~abuckley/308.pdf, considering Markus' recent comments and adding a summary of API changes. The full SE 8 API will be presented in the Umbrella JSR's Public Review. Comments are welcome any time on type-annotation-spec-experts or -comments, though you may wish to batch up your comments and submit them during throughout the PR period. Alex From srikanth_sankaran at in.ibm.com Mon Oct 21 05:39:38 2013 From: srikanth_sankaran at in.ibm.com (Srikanth S Adayapalam) Date: Mon, 21 Oct 2013 18:09:38 +0530 Subject: Eclipse compiler support for JSR308 & JSR269 enhancements for Java8. Message-ID: Dear EG & Observers, A brief note to inform you that the Eclipse compiler team announced the completion of work on these projects, has made available early access builds and is inviting users to test and report defects. You can see the announcement here: http://dev.eclipse.org/mhonarc/lists/eclipse-dev/msg09679.html All follow ups & defect reports should go to the appropriate forums referenced in that page and not here. Thanks! Srikanth. From mernst at cs.washington.edu Tue Oct 22 09:05:41 2013 From: mernst at cs.washington.edu (Michael Ernst) Date: Tue, 22 Oct 2013 09:05:41 -0700 (PDT) Subject: "final" ReceiverParameter? In-Reply-To: References: <525EDBC6.3030101@oracle.com> Message-ID: <20131022.090541.1684971364642419784.mernst@cs.washington.edu> I concur with both of these comments. Thanks, Markus, for your careful reading! -Mike > Subject: "final" ReceiverParameter? (was: Public Review for JSR 308) > From: Markus Keller > To: type-annotations-spec-comments at openjdk.java.net > Date: Mon, 21 Oct 2013 17:32:16 +0200 > > Alex Buckley wrote on 2013-10-16 20:32:38: > >> http://cr.openjdk.java.net/~abuckley/308.pdf > > Two more nits: > > 1. > > ReceiverParameter: > {VariableModifier} UnannType {Identifier .} this > > VariableModifier syntactically allows annotations and "final". I don't > think "final" makes sense here, not even optional. {VariableModifier} > would better be replaced by {Annotation}. Otherwise, we'd need some spec > text that tells that "final" is not a legal modifier for a receiver > parameter. > > 2. Typo on p.18: "that type is the type is the newly constructed object" > => 2nd "is" should be "of" ^^ > > Markus From mernst at cs.washington.edu Tue Oct 22 10:11:07 2013 From: mernst at cs.washington.edu (Michael Ernst) Date: Tue, 22 Oct 2013 10:11:07 -0700 (PDT) Subject: Clarifying the receiver parameter In-Reply-To: References: <525DC83D.4040104@oracle.com> Message-ID: <20131022.101107.1682533952140077700.mernst@cs.washington.edu> Markus just gave us a link to his April email. (I didn't see that message either, unfortunately.) I'm pasting Markus's April message here for the record. -Mike > From: Markus Keller markus_keller at ch.ibm.com > Date: Wed Apr 24 04:24:16 PDT 2013 > To: type-annotations-spec-observers > > The difference is that we're not talking about a 'this' expression here, > but about the *declaration* of a method/constructor parameter. > > For references to 'this', qualification is necessary in general to > support references to all enclosing instances. Since the grammar already > allows qualifiers, it makes sense to keep full generality and also allow > redundant qualifiers there. > > But there's no point in adding qualifiers for the declaration of the > 'this' parameter of an instance method. The reason is consistency with > all other declarations. You also cannot qualify a method name, > constructor name, field name, or type name in a declaration. > > For constructors, the 308 spec decided to annotate the whole > constructor, rather than allowing an explicit 'this' parameter like for > instance methods. This works fine for top-level constructors, but it > doesn't offer a way to annotate enclosing types of an inner class > constructor. The syntactic kludge to allow annotations on the enclosing > types is the superclass.'this' parameter on inner class constructors. A > pure 'this' would declare the wrong element, so it needs to be > qualified. And like the enclosing class' simple name is enough for a > constructor name, the outer class' simple name is also enough to qualify > the 'this' parameter of an inner class constructor. > > An alternative to the current spec would be to drop section 2.1 point 4 > : "A type annotation is permitted in front of a constructor declaration, > [..]". Instead of that, we could allow a 'this' receiver parameter for > all constructors, where the 'this' would point to the constructed > object. This would obviate the need for any qualification on 'this', but > it has the drawback that TYPE_USE annotations on the whole constructor > declaration could clash with annotations on the 'this' parameter's type. > I think the rationale for the current design is to avoid this clash. > > Markus From mernst at cs.washington.edu Tue Oct 22 10:29:06 2013 From: mernst at cs.washington.edu (Michael Ernst) Date: Tue, 22 Oct 2013 10:29:06 -0700 (PDT) Subject: Clarifying the receiver parameter In-Reply-To: <20131022.101107.1682533952140077700.mernst@cs.washington.edu> References: <525DC83D.4040104@oracle.com> <20131022.101107.1682533952140077700.mernst@cs.washington.edu> Message-ID: <20131022.102906.1518626036282809992.mernst@cs.washington.edu> There seems to be a bit of confusion between the result of a constructor and the receiver of a constructor. (I'm focusing for the purpose of this discussion on inner class constructors, which are the only ones that have receivers.) Recall that constructor receivers and constructor results are completely different concepts. (But Java's slightly odd naming conventions make them easy to confuse!) * in a (non-constructor) method, the receiver is named "this" * in a (non-constructor) method, there is no special name for result; the result is just whatever expression appears in the return statement * in a top-level constructor, there is no receiver * in an inner class constructor, the receiver is named "Outer.this". It cannot be referred to as "this", because "this" means something else, namely the result. * in a constructor, the result is named "this", and there is no explicit return statement Writing "this" as the name of the receiver in a constructor declaration would be incorrect, and one must write "Outer.this" to disambiguate. This is exactly the same as the case within the constructor body: to refer to the result, one uses "this", but to refer to the receiver, one uses "Outer.this". So, the declaration is consistent with usage within the method body. It would be rather confusing for "this" to mean one thing in the declaration and a different thing in the body. I hope this explains the rationale and helps to answer Srikanth's and Markus's questions. -Mike From alex.buckley at oracle.com Tue Oct 22 14:13:44 2013 From: alex.buckley at oracle.com (Alex Buckley) Date: Tue, 22 Oct 2013 14:13:44 -0700 Subject: "final" ReceiverParameter? In-Reply-To: <20131022.090541.1684971364642419784.mernst@cs.washington.edu> References: <525EDBC6.3030101@oracle.com> <20131022.090541.1684971364642419784.mernst@cs.washington.edu> Message-ID: <5266EA88.4000907@oracle.com> I also agree with syntactically disallowing 'final' on a receiver parameter, for three reasons: 1. Historically, 'final' was disallowed in the java-annotation-design.pdf document: the FormalParameterOrReceiverDecls production did not allow VariableModifier terms before the receiver parameter (section 2.2 item 5). A recent javac allows 'final' in this location, which is a bug. 2. Conceptually, the receiver parameter has no effect on the rest of the code - it is specified as "an optional syntactic device" - so it would be confusing for an effect-free 'final' to appear. 3. Semantically, 'final' is a modifier for a _variable_, while 'this' is not a variable (it is a keyword that denotes a value) and the receiver parameter is not a variable declaration. So, the idea of a "final 'this'" is unsound. I will modify the ReceiverParameter production in the JLS draft to use {Annotation} rather than {VariableModifier}. Alex On 10/22/2013 9:05 AM, Michael Ernst wrote: > I concur with both of these comments. Thanks, Markus, for your careful reading! > > -Mike > > >> Subject: "final" ReceiverParameter? (was: Public Review for JSR 308) >> From: Markus Keller >> To: type-annotations-spec-comments at openjdk.java.net >> Date: Mon, 21 Oct 2013 17:32:16 +0200 >> >> Alex Buckley wrote on 2013-10-16 20:32:38: >> >>> http://cr.openjdk.java.net/~abuckley/308.pdf >> >> Two more nits: >> >> 1. >> >> ReceiverParameter: >> {VariableModifier} UnannType {Identifier .} this >> >> VariableModifier syntactically allows annotations and "final". I don't >> think "final" makes sense here, not even optional. {VariableModifier} >> would better be replaced by {Annotation}. Otherwise, we'd need some spec >> text that tells that "final" is not a legal modifier for a receiver >> parameter. >> >> 2. Typo on p.18: "that type is the type is the newly constructed object" >> => 2nd "is" should be "of" ^^ >> >> Markus From alex.buckley at oracle.com Tue Oct 22 14:21:45 2013 From: alex.buckley at oracle.com (Alex Buckley) Date: Tue, 22 Oct 2013 14:21:45 -0700 Subject: Eclipse compiler support for JSR308 & JSR269 enhancements for Java8. In-Reply-To: References: Message-ID: <5266EC69.8010700@oracle.com> That's great news! Many congratulations to the Eclipse team. In addition to the Acknowledgements section at that page, I would like to recognize Markus Keller for his thorough analysis of JSR 308 specification materials and his resulting detailed comments. Alex On 10/21/2013 5:39 AM, Srikanth S Adayapalam wrote: > Dear EG & Observers, > > A brief note to inform you that the Eclipse compiler team > announced the completion of work on > these projects, has made available early access builds and is inviting > users to test and report defects. > > You can see the announcement here: > http://dev.eclipse.org/mhonarc/lists/eclipse-dev/msg09679.html > All follow ups & defect reports should go to the appropriate forums > referenced in that page and not here. > > Thanks! > Srikanth. > From alex.buckley at oracle.com Wed Oct 23 11:27:25 2013 From: alex.buckley at oracle.com (Alex Buckley) Date: Wed, 23 Oct 2013 11:27:25 -0700 Subject: Clarifying the receiver parameter (qualified 'this') In-Reply-To: References: <525DC83D.4040104@oracle.com> <20131022.101107.1682533952140077700.mernst@cs.washington.edu> <20131022.102906.1518626036282809992.mernst@cs.washington.edu> Message-ID: <5268150D.2070008@oracle.com> On 10/23/2013 3:47 AM, Markus Keller wrote: > In reply to Michael Ernst 's > http://mail.openjdk.java.net/pipermail/type-annotations-spec-experts/2013-October/000159.html > > Yes, we're not at all questioning the "Outer.this" notation for inner > class constructors. > > I just find it awkward that the 308.pdf replaced > java-annotation-design.html's > [Identifier .] this > with > {Identifier .} this > and allows (fully-)qualified 'this' expressions as the name of the > receiver parameter even where that's not necessary. > > The argument about analogy to qualified 'this' expressions in a method > body is IMO too far-fetched, since the receiver parameter is closer to > being a declaration rather than a reference. The receiver parameter is _not_ "closer to being a declaration", as 308.pdf makes clear: "It is not a formal parameter. More precisely, it is not a declaration of any kind of variable (4.12.3), is never bound to any value passed as an argument in a method invocation expression, and has no effect whatsoever at run time." As Mike pointed out, there is a pleasing consistency between the name of the receiver parameter and the name in a qualified this expression in the ctor body - both reflect the type of the immediately enclosing instance which may in general be qualified, e.g. pkg1.pkg2.Outer. > By the same argument, you > would also have to allow other names in declarations to be redundantly > qualified, e.g.: > > package my.pack; > public class my.pack.Example { // illegal (good) > my.pack.Example() { } // illegal (good) > void my.pack.Example.foo() { } // illegal (good) > void bar(@Const Example my.pack.Example.this) { } // should be > illegal > } The premise of the above paragraph - that the receiver parameter is a declaration made with a qualified name - is false so the example is ill-conceived. A declaration of a class, a constructor, a method, a formal parameter uses a simple name by definition. Alex From mernst at cs.washington.edu Wed Oct 23 14:34:10 2013 From: mernst at cs.washington.edu (Michael Ernst) Date: Wed, 23 Oct 2013 14:34:10 -0700 (PDT) Subject: Clarifying the receiver parameter (qualified 'this') In-Reply-To: References: <20131022.101107.1682533952140077700.mernst@cs.washington.edu> <20131022.102906.1518626036282809992.mernst@cs.washington.edu> Message-ID: <20131023.143410.529884525787026761.mernst@cs.washington.edu> Markus- Thanks for your helpful and clear message; now I understand your point. > I just find it awkward that the 308.pdf replaced > java-annotation-design.html's > [Identifier .] this > with > {Identifier .} this > and allows (fully-)qualified 'this' expressions as the name of the > receiver parameter even where that's not necessary. I'd like to treat these as two separate issues. First, the change from [Identifier .] this to {Identifier .} this was essential. The reason is that inside a doubly-nested inner class, the receiver can have a name like Outer.Middle.this. The second issue is whether the specification should add a separate note that states that when writing {Identifier .} this all the Identifiers must be outer class names and are forbidden from being package names. In other words, the question is whether to create a new class of compiler errors that the compiler was forced to emit. This adds complexity to the Java specification and to compiler implementations and test suites. I do agree with you in terms of code style. When writing the receiver, I would advise programmers not to write a fully-qualified type -- that is, not to write the package components. (Regarding rationale, it's true that the receiver looks like other formal parameters in some ways, but it is different in other ways -- including not allowing modifiers like "final" and not being a simple name because it permits dots as in "Outer.this". So absolute syntactic similarity with formal parameters is not possible.) That said, it is not the compiler's job to enforce good code style. The fact that this is a style point is a good argument against adding this complexity to the specification. The presence or absence of package names will have at most a minor impact on programmers. I don't see much harm in either choice, and style guidelines and tools can set their own standards. Thus, it doesn't feel like it is worth adding complexity to the language definition and to compilers, just to prevent package names from being written by programmers. -Mike From mernst at cs.washington.edu Thu Oct 24 06:10:51 2013 From: mernst at cs.washington.edu (Michael Ernst) Date: Thu, 24 Oct 2013 06:10:51 -0700 (PDT) Subject: @Target mixing TYPE_USE and declaration annotation In-Reply-To: References: <525EDBC6.3030101@oracle.com> Message-ID: <20131024.061051.1928306862603393273.mernst@cs.washington.edu> Markus- You are arguing for forbidding certain combinations of ElementType fields in an @Target meta-annotation. This is something that has never been done in the Java spec before. Your argument is based on one specific use case, but other use cases may exist. I have many times been surprised by how people have come up with unanticipated uses for my designs. I'm reluctant to complicate the specification and reduce flexibility and generality, just to prevent one specific use case. I would rather let the authors of annotations and annotation processors decide how to use them, what the semantics is, and how to support Java SE 7 uses if necessary. The transition affects only a very small number of people, and your view of it may be different than other people's view. Advice about current best practice in using ElementTypes in a @Target meta-annotation could go in the ElementType documentation, where it would be more appropriate, and more likely to be read, than in the JSR 308 specification. Also, annotation processors don't "attach" annotations to anything -- they merely interpret them. The annotations are attached to the AST by the compiler in a well-defined way, depending on the @Target meta-annotation. Thanks for the comments! -Mike > Subject: @Target mixing TYPE_USE and declaration annotation > From: Markus Keller > To: type-annotations-spec-comments at openjdk.java.net > Date: Tue, 22 Oct 2013 20:04:50 +0200 > > To finish the series of mails lost in the maligned observers list, I want > to mention > http://mail.openjdk.java.net/pipermail/type-annotations-spec-observers/2013-April/000152.html > > The gist is that allowing @Target annotations with a mixture of TYPE_USE > and declaration elements is not only bad for implementers of annotation > processors, but also for users of such annotations. I'm still convinced > that mixing TYPE_USE with other targets should be forbidden. > > Page 20 of 308-20131016.pdf has such an example: >> ------- > If TA is additionally meta-annotated with @Target(ElementType.FIELD), > then > the term > @TA java.lang.Object is legal in locations which are both declaration and > type contexts, > such as a field declaration @TA java.lang.Object f;. Here, @TA is deemed > to apply > to the declaration of f (and not to the type java.lang.Object) because TA > is applicable > in the field declaration context. >> ------- > > Because an annotation can only have a single @Target annotation, the > beginning would better be written as: "If TA is meta-annotated with > @Target({ElementType.TYPE_USE, ElementType.FIELD}), ...". > > And the example hides the even worse ramifications for array-typed > fields: > > @TA Object[] f2; > > The SE 7 APIs consider @TA an annotation on field f2. > The SE 8 APIs consider @TA also a type annotation on Object (not on the > field type Object[]!). > > Now what does that mean e.g. for "@Nullable Object[] f2;"? If an > annotation processor wants to be source-compatible with SE 7 code, then > it > cannot rely on the SE 8 meaning of such a mixed-target annotation! > Although the 308 spec attaches the type annotation to the type "Object", > the annotation processor still has to adhere to the legacy meaning and > must attach it to "Object[]". I.e. it effectively *cannot* make use of > the > added TYPE_USE element type in this case. > > If an annotation provider doesn't care about these corner cases with > qualified and array types, then he can just switch to @Target(TYPE_USE). > Otherwise, he should deprecate the old declaration annotation and declare > a new type annotation. > > The current JSR 308 proposal doesn't tell that mixing target elements is > considered bad style nor that it is discouraged. > > http://types.cs.washington.edu/jsr308/specification/java-annotation-design.html > says: >> Note from the above examples that a programmer is permitted to write can > write a @Target meta-annotation indicating that an annotation, such as > @FTAnno or @MTAnno, is both a type annotation and a declaration > annotation. We have not found an example where such a meta-annotation is > desirable for a newly-created annotation; although it is legal, it is > considered bad style. By contrast, when migrating from Java SE 7 and > older > annotation processors to Java SE 8 and newer annotation processors, it > may > be desirable for the annotation to be both a type annotation and a > declaration annotation, for reasons of backward compatibility. > > The last sentence about migration was only added in the very last > revision, and it gives a very bad advice that locks annotation providers > and users into an eternal backwards-compatibility mode. > > Summary: The spec allows a bad style for compatibility reasons, but it > effectively fails to deliver that promise. Backwards compatibility and > correct treatment of TYPE_USE exclude each other, and the spec should not > make it appear like there is a solution. > > If it's too late for this change, then the spec should at least tell that > mixed-target annotation types are dangerous and discouraged. > > Markus From mernst at cs.washington.edu Thu Oct 24 06:56:24 2013 From: mernst at cs.washington.edu (Michael Ernst) Date: Thu, 24 Oct 2013 06:56:24 -0700 (PDT) Subject: Clarifying the receiver parameter (qualified 'this') In-Reply-To: References: <20131023.143410.529884525787026761.mernst@cs.washington.edu> Message-ID: <20131024.065624.1287272439804802138.mernst@cs.washington.edu> Markus- >> First, the change from >> [Identifier .] this >> to >> {Identifier .} this >> was essential. The reason is that inside a doubly-nested inner class, > the >> receiver can have a name like Outer.Middle.this. > > Nope, Middle.this is always equivalent to Outer.Middle.this, so the > "Outer." is never necessary. You're right. It's necessary on the type, but it is not necessary (nor does it serve any purpose for disambiguation) on the "this", which is what we are talking about. Thanks for the correction. -Mike From dl at cs.oswego.edu Thu Oct 24 11:53:01 2013 From: dl at cs.oswego.edu (Doug Lea) Date: Thu, 24 Oct 2013 14:53:01 -0400 Subject: Clarifying the receiver parameter (qualified 'this') In-Reply-To: <20131023.143410.529884525787026761.mernst@cs.washington.edu> References: <20131022.101107.1682533952140077700.mernst@cs.washington.edu> <20131022.102906.1518626036282809992.mernst@cs.washington.edu> <20131023.143410.529884525787026761.mernst@cs.washington.edu> Message-ID: <52696C8D.7090201@cs.oswego.edu> I confess that, as soon as I noticed that the disputed issues are only to annotate inner classes nested at least two deep, I stopped caring much about outcome -- it will impact very few programs. If I ever encountered it, I'd probably recheck the specs/JLS anyway, so I don't have any expectations about naturalness. Given all that, I support the position that there is no real need to change things. The name "Outer.this" is only needed to distinguish from "this", and no extra qualification is needed. So the only question is whether it would be OK to allow extra qualification anyway. Unless someone comes up with a compelling reason, I'm fine with not allowing it. -Doug On 10/23/2013 05:34 PM, Michael Ernst wrote: > > The second issue is whether the specification should add a separate note that > states that when writing > > {Identifier .} this > > all the Identifiers must be outer class names and are forbidden from being > package names. In other words, the question is whether to create a new class of > compiler errors that the compiler was forced to emit. This adds complexity to > the Java specification and to compiler implementations and test suites. > > I do agree with you in terms of code style. When writing the receiver, I would > advise programmers not to write a fully-qualified type -- that is, not to write > the package components. (Regarding rationale, it's true that the receiver looks > like other formal parameters in some ways, but it is different in other ways -- > including not allowing modifiers like "final" and not being a simple name > because it permits dots as in "Outer.this". So absolute syntactic similarity > with formal parameters is not possible.) > > That said, it is not the compiler's job to enforce good code style. The fact > that this is a style point is a good argument against adding this complexity to > the specification. > > The presence or absence of package names will have at most a minor impact on > programmers. I don't see much harm in either choice, and style guidelines and > tools can set their own standards. Thus, it doesn't feel like it is worth > adding complexity to the language definition and to compilers, just to prevent > package names from being written by programmers. > > -Mike > From alex.buckley at oracle.com Thu Oct 24 13:00:28 2013 From: alex.buckley at oracle.com (Alex Buckley) Date: Thu, 24 Oct 2013 13:00:28 -0700 Subject: Clarifying the receiver parameter (qualified 'this') In-Reply-To: <52696C8D.7090201@cs.oswego.edu> References: <20131022.101107.1682533952140077700.mernst@cs.washington.edu> <20131022.102906.1518626036282809992.mernst@cs.washington.edu> <20131023.143410.529884525787026761.mernst@cs.washington.edu> <52696C8D.7090201@cs.oswego.edu> Message-ID: <52697C5C.6010102@oracle.com> It appears that the will of the EG regarding an inner class's constructor is that the name of the receiver parameter must be qualified by only a single Identifier. Allowing any name which could notionally serve as a qualified this expression in the ctor body has not found favor. Accordingly, I will change the JLS/JVMS draft to use "[Identifier .] this" as found in the java-annotation-design document. Markus pointed out other infelicities concerning inner class constructors in the JLS/JVMS draft, so I will clarify all of this in one pass. Alex On 10/24/2013 11:53 AM, Doug Lea wrote: > > I confess that, as soon as I noticed that the disputed > issues are only to annotate inner classes nested at least two deep, > I stopped caring much about outcome -- it will impact very > few programs. If I ever encountered it, I'd probably recheck > the specs/JLS anyway, so I don't have any expectations about > naturalness. > > Given all that, I support the position that there is no > real need to change things. The name "Outer.this" is > only needed to distinguish from "this", and no extra > qualification is needed. So the only question is > whether it would be OK to allow extra qualification anyway. > Unless someone comes up with a compelling reason, I'm > fine with not allowing it. > > -Doug > > > On 10/23/2013 05:34 PM, Michael Ernst wrote: >> >> The second issue is whether the specification should add a separate >> note that >> states that when writing >> >> {Identifier .} this >> >> all the Identifiers must be outer class names and are forbidden from >> being >> package names. In other words, the question is whether to create a >> new class of >> compiler errors that the compiler was forced to emit. This adds >> complexity to >> the Java specification and to compiler implementations and test suites. >> >> I do agree with you in terms of code style. When writing the >> receiver, I would >> advise programmers not to write a fully-qualified type -- that is, not >> to write >> the package components. (Regarding rationale, it's true that the >> receiver looks >> like other formal parameters in some ways, but it is different in >> other ways -- >> including not allowing modifiers like "final" and not being a simple name >> because it permits dots as in "Outer.this". So absolute syntactic >> similarity >> with formal parameters is not possible.) >> >> That said, it is not the compiler's job to enforce good code style. >> The fact >> that this is a style point is a good argument against adding this >> complexity to >> the specification. >> >> The presence or absence of package names will have at most a minor >> impact on >> programmers. I don't see much harm in either choice, and style >> guidelines and >> tools can set their own standards. Thus, it doesn't feel like it is >> worth >> adding complexity to the language definition and to compilers, just to >> prevent >> package names from being written by programmers. >> >> -Mike >> >