From elena.votchennikova at oracle.com Tue Oct 1 06:54:46 2013 From: elena.votchennikova at oracle.com (elena votchennikova) Date: Tue, 01 Oct 2013 17:54:46 +0400 Subject: j.l.r.Parameter.hashCode() question Message-ID: <524AD426.7000702@oracle.com> Hello, the API spec to the j.l.r.Parameter.hashCode() method says "Returns a hash code based on the executable's hash code and the index." Could you please explain me does this mean that the hash codes must be identical for the two Parameters with the same executables and the same indexes and the hash codes must be different for the Parameters with different executables or indexes? What does mean "based" in this context? Thanks a lot, Elena From jesper at selskabet.org Tue Oct 1 13:05:08 2013 From: jesper at selskabet.org (=?iso-8859-1?Q?Jesper_Steen_M=F8ller?=) Date: Tue, 1 Oct 2013 22:05:08 +0200 Subject: Example in 8misc.pdf re. containing annotations Message-ID: <3109652E-6963-42CB-963F-F124F1D8FD95@selskabet.org> Hi List The example of declared targets (Section 9.6) has an example, which I think is in error: An annotation whose type declaration indicates a target of java.lang.annotation.ElementType.TYPE can appear in at least as many locations as an annotation whose type declaration indicates a target of java.lang.annotation.ElementType.ANNOTATION_TYPE. For example, given the following declarations of repeatable and containing annotation types: @Target(ElementType.TYPE) @ContainedBy(FooContainer.class) @interface Foo {} @Target(ElementType.ANNOTATION_TYPE) @ContainerFor(Foo.class) @Interface FooContainer { Foo[] value(); } Is this from an earlier version, so that @ContainedBy should be @Repeatable, and @ContainerFor should be omitted? Kind regards, Jesper From jesper at selskabet.org Tue Oct 1 13:20:21 2013 From: jesper at selskabet.org (=?iso-8859-1?Q?Jesper_Steen_M=F8ller?=) Date: Tue, 1 Oct 2013 22:20:21 +0200 Subject: @Target on Repeatable annotation but no @Target on the containing annotation Message-ID: Hi List Consider the following example: import java.lang.annotation.Target; import java.lang.annotation.ElementType; @interface FooContainer { Foo[] value(); } @java.lang.annotation.Repeatable(FooContainer.class) @java.lang.annotation.Target({ElementType.FIELD}) @interface Foo { } The spec doesn't address this case as directly as it handles the others - but as I read it, then since @Foo is constrained to specific targets, and @FooContainer is not, this should be flagged as an error, right? -Jesper From alex.buckley at oracle.com Tue Oct 1 15:55:00 2013 From: alex.buckley at oracle.com (Alex Buckley) Date: Tue, 01 Oct 2013 15:55:00 -0700 Subject: Example in 8misc.pdf re. containing annotations In-Reply-To: <3109652E-6963-42CB-963F-F124F1D8FD95@selskabet.org> References: <3109652E-6963-42CB-963F-F124F1D8FD95@selskabet.org> Message-ID: <524B52C4.9000607@oracle.com> I was sure I'd removed all mention of @ContainedBy / @ContainerFor ! Thanks for spotting that, clearly it should be: @Target(ElementType.TYPE) @Repeatable(FooContainer.class) @interface Foo {} @Target(ElementType.ANNOTATION_TYPE) @Interface FooContainer { Foo[] value(); } Alex On 10/1/2013 1:05 PM, Jesper Steen M?ller wrote: > Hi List > > The example of declared targets (Section 9.6) has an example, which I think is in error: > An annotation whose type declaration indicates a target of java.lang.annotation.ElementType.TYPE can appear in at least as many locations as an annotation whose type declaration indicates a target of java.lang.annotation.ElementType.ANNOTATION_TYPE. For example, given the following declarations of repeatable and containing annotation types: > > @Target(ElementType.TYPE) > @ContainedBy(FooContainer.class) > @interface Foo {} > @Target(ElementType.ANNOTATION_TYPE) > @ContainerFor(Foo.class) > @Interface FooContainer { > Foo[] value(); > } > Is this from an earlier version, so that @ContainedBy should be @Repeatable, and @ContainerFor should be omitted? > > Kind regards, > Jesper > From alex.buckley at oracle.com Tue Oct 1 16:02:08 2013 From: alex.buckley at oracle.com (Alex Buckley) Date: Tue, 01 Oct 2013 16:02:08 -0700 Subject: @Target on Repeatable annotation but no @Target on the containing annotation In-Reply-To: References: Message-ID: <524B5470.1050501@oracle.com> You are correct. FooContainer is applicable in all the locations where it was applicable in SE 7 (JSR 308 has a fuller explanation of this), which is to say, type declarations and method declarations and field declarations and so on. Foo must be applicable to at least those same locations, but it isn't. Technically, in the code below, FooContainer is not a containing annotation type of Foo, and javac correctly gives an error for @Repeatable(FooContainer.class). Alex On 10/1/2013 1:20 PM, Jesper Steen M?ller wrote: > Hi List > > Consider the following example: > > import java.lang.annotation.Target; > import java.lang.annotation.ElementType; > > @interface FooContainer { > Foo[] value(); > } > > @java.lang.annotation.Repeatable(FooContainer.class) > @java.lang.annotation.Target({ElementType.FIELD}) > @interface Foo { > } > > The spec doesn't address this case as directly as it handles the others - but as I read it, then since @Foo is constrained to specific targets, and @FooContainer is not, this should be flagged as an error, right? > > -Jesper > From joe.darcy at oracle.com Thu Oct 3 18:03:38 2013 From: joe.darcy at oracle.com (Joseph Darcy) Date: Thu, 03 Oct 2013 18:03:38 -0700 Subject: j.l.r.Parameter.hashCode() question In-Reply-To: <524AD426.7000702@oracle.com> References: <524AD426.7000702@oracle.com> Message-ID: <524E13EA.3040406@oracle.com> Hello Elena, The general requirements from Object.hashCode hold: equal objects must have equal hash codes. (Of necessity, unequal objects may have the same hash code.) The phrased "based on" means "some unspecified function of." It is generally undesirable to exactly specify a hash code function when you don't absolutely have to. HTH, -Joe On 10/1/2013 6:54 AM, elena votchennikova wrote: > Hello, > > the API spec to the j.l.r.Parameter.hashCode() method says "Returns a > hash code based on the executable's hash code and the index." > Could you please explain me does this mean that the hash codes must be > identical for the two Parameters with the same executables and the > same indexes and the hash codes must be different for the Parameters > with different executables or indexes? > What does mean "based" in this context? > > > Thanks a lot, > Elena From elena.votchennikova at oracle.com Fri Oct 4 03:49:12 2013 From: elena.votchennikova at oracle.com (elena votchennikova) Date: Fri, 04 Oct 2013 14:49:12 +0400 Subject: j.l.r.Parameter.hashCode() question In-Reply-To: <524E13EA.3040406@oracle.com> References: <524AD426.7000702@oracle.com> <524E13EA.3040406@oracle.com> Message-ID: <524E9D28.8060305@oracle.com> Hi Joe, thank you for the replay, On 04.10.2013 5:03, Joseph Darcy wrote: > Hello Elena, > > The general requirements from Object.hashCode hold: equal objects must > have equal hash codes. (Of necessity, unequal objects may have the > same hash code.) Yep. > > The phrased "based on" means "some unspecified function of." It is > generally undesirable to exactly specify a hash code function when you > don't absolutely have to. So, do you mean that the executable and the index are just used in this "unspecified function" or do you want to say that if the executable and the index are same, then the hash codes will be the same? I just want to clarify it, because if the answer is "yes" then I think this is not obviously from the wording "based on". And if the answer is "no", that this is Ok. But in the spec to the equals() method we have the same wording: "Compares based on the executable and the index.". But what does this exactly mean? Thank you for your help, Elena > > HTH, > > -Joe > > On 10/1/2013 6:54 AM, elena votchennikova wrote: >> Hello, >> >> the API spec to the j.l.r.Parameter.hashCode() method says "Returns a >> hash code based on the executable's hash code and the index." >> Could you please explain me does this mean that the hash codes must >> be identical for the two Parameters with the same executables and the >> same indexes and the hash codes must be different for the Parameters >> with different executables or indexes? >> What does mean "based" in this context? >> >> >> Thanks a lot, >> Elena > From joe.darcy at oracle.com Fri Oct 4 10:14:44 2013 From: joe.darcy at oracle.com (Joe Darcy) Date: Fri, 04 Oct 2013 10:14:44 -0700 Subject: j.l.r.Parameter.hashCode() question In-Reply-To: <524E9D28.8060305@oracle.com> References: <524AD426.7000702@oracle.com> <524E13EA.3040406@oracle.com> <524E9D28.8060305@oracle.com> Message-ID: <524EF784.4090706@oracle.com> Hello Elena, On 10/04/2013 03:49 AM, elena votchennikova wrote: > Hi Joe, > > thank you for the replay, > > On 04.10.2013 5:03, Joseph Darcy wrote: >> Hello Elena, >> >> The general requirements from Object.hashCode hold: equal objects >> must have equal hash codes. (Of necessity, unequal objects may have >> the same hash code.) > Yep. >> >> The phrased "based on" means "some unspecified function of." It is >> generally undesirable to exactly specify a hash code function when >> you don't absolutely have to. > So, do you mean that the executable and the index are just used in > this "unspecified function" or do you want to say that if the > executable and the index are same, then the hash codes will be the same? > > I just want to clarify it, because if the answer is "yes" then I think > this is not obviously from the wording "based on". And if the answer > is "no", that this is Ok. > But in the spec to the equals() method we have the same wording: > "Compares based on the executable and the index.". But what does this > exactly mean? > > > Thank you for your help, > Elena It it implicit that the hashCode and equals mehtods on Parameter follow the general hashCode and equals contract. Equality is based on executable and index; I don't think it is helpful to write specification that is equivalent to the implementation of if(obj instanceof Parameter) { Parameter other = (Parameter)obj; return (other.executable.equals(executable) && other.index == index); } return false; We do not want to specify the hash function; it is sufficient to say it takes the executable and index as inputs. Cheers, -Joe From forax at univ-mlv.fr Fri Oct 4 11:56:22 2013 From: forax at univ-mlv.fr (Remi Forax) Date: Fri, 04 Oct 2013 20:56:22 +0200 Subject: j.l.r.Parameter.hashCode() question In-Reply-To: <524EF784.4090706@oracle.com> References: <524AD426.7000702@oracle.com> <524E13EA.3040406@oracle.com> <524E9D28.8060305@oracle.com> <524EF784.4090706@oracle.com> Message-ID: <524F0F56.1050707@univ-mlv.fr> On 10/04/2013 07:14 PM, Joe Darcy wrote: > Hello Elena, > > On 10/04/2013 03:49 AM, elena votchennikova wrote: >> Hi Joe, >> >> thank you for the replay, >> >> On 04.10.2013 5:03, Joseph Darcy wrote: >>> Hello Elena, >>> >>> The general requirements from Object.hashCode hold: equal objects >>> must have equal hash codes. (Of necessity, unequal objects may have >>> the same hash code.) >> Yep. >>> >>> The phrased "based on" means "some unspecified function of." It is >>> generally undesirable to exactly specify a hash code function when >>> you don't absolutely have to. >> So, do you mean that the executable and the index are just used in >> this "unspecified function" or do you want to say that if the >> executable and the index are same, then the hash codes will be the same? >> >> I just want to clarify it, because if the answer is "yes" then I >> think this is not obviously from the wording "based on". And if the >> answer is "no", that this is Ok. >> But in the spec to the equals() method we have the same wording: >> "Compares based on the executable and the index.". But what does this >> exactly mean? >> >> >> Thank you for your help, >> Elena > > It it implicit that the hashCode and equals mehtods on Parameter > follow the general hashCode and equals contract. > > Equality is based on executable and index; I don't think it is helpful > to write specification that is equivalent to the implementation of > > if(obj instanceof Parameter) { > Parameter other = (Parameter)obj; > return (other.executable.equals(executable) && > other.index == index); > } > return false; It's unrelated to the current discussion but if the code is effectively this one, may I suggest an improvement, given that && is lazy, it's better to test the index first and then test the executable if needed. > > We do not want to specify the hash function; it is sufficient to say > it takes the executable and index as inputs. > > Cheers, > > -Joe cheers, R?mi From alex.buckley at oracle.com Thu Oct 10 10:47:14 2013 From: alex.buckley at oracle.com (Alex Buckley) Date: Thu, 10 Oct 2013 10:47:14 -0700 Subject: Behavior of getAnnotationsByType for @FooContainer({}) In-Reply-To: <525678AA.6010007@oracle.com> References: <525678AA.6010007@oracle.com> Message-ID: <5256E822.8040607@oracle.com> // Moving question to the enhanced-metadata-spec-discuss list. I need to know the definitions of Foo and FooContainer, plus the actual method call you're making. I assume it's B.class.getAnnotationsByType(SOMETHING) but I don't know what the SOMETHING is. Your code is similar to Example 1.2-4 in http://cr.openjdk.java.net/~abuckley/8misc.pdf - please identify how your setup differs from the setup there. Alex On 10/10/2013 2:51 AM, Andreas Lundblad wrote: > Joel, Joe, Alex > > As far as I can tell, the behavior of getAnnotationsByType is not > clearly defined for the following case > > @Foo class A {} > @FooContainer({}) class B extends A {} > > Should it be interpreted as > > 1) Since no @Foos are directly or indirectly present on B, @Foo should > be inherited from A > > or > > 2) The explicit (empty) list of @Foos prevent any other @Foos from being > inherited. > > Unless I've overlooked something and there is a good reason to define it > as alternative 1, I would prefer alternative 2, as it seems strange to > let the semantics depend on the length of the list. > > best regards, > Andreas Lundblad From alex.buckley at oracle.com Fri Oct 11 12:45:47 2013 From: alex.buckley at oracle.com (Alex Buckley) Date: Fri, 11 Oct 2013 12:45:47 -0700 Subject: Behavior of getAnnotationsByType for @FooContainer({}) In-Reply-To: <5257A806.5090502@oracle.com> References: <525678AA.6010007@oracle.com> <5256E822.8040607@oracle.com> <5257A806.5090502@oracle.com> Message-ID: <5258556B.3030107@oracle.com> Hi Andreas, In Java SE 7, an @Foo on class A is visible on class B - class B "bought in" to that policy when it subclassed A. And so, in SE 7, the only way to "prevent" A's @Foo from being visible on B is for B to have a directly-present @Foo. That doesn't change in SE 8 - we just allow B to have one @Foo (directly-present) or many (indirectly-present). More generally, as a general principle, a thing is inherited unless overridden by a thing of the same name. And so, for the new get[Declared]AnnotationsByType methods in AnnotatedElement, we try hard to "look through" the container annotation and reason solely about annotations of the type which the user actually queried (Foo.class). In this model, it's undesirable to say that @FooContainer on B overrides @Foo on A. Alex On 10/11/2013 12:25 AM, Andreas Lundblad wrote: > The question is how B.class.getAnnotationsByType(Foo.class) should > behave in the presence of: > > @Inherited > @interface FooContainer { > Foo[] value(); > } > > @Inherited > @Repeated(FooContainer.class) > @interface Foo {} > > @Foo class A {} > @FooContainer({}) class B {} > > > It is indeed quite similar to Example 1.2-4, except that in this case > the FooContainer is empty. Strictly speaking this causes the second > condition of the associated-definition to hold: > > "No annotation of Foo's type is directly or indirectly present on B, and > B is a class, and Foo's type is inheritable, and Foo is associated with > the superclass of B." > > This is, to me at least, a bit counter intuitive (and it prevents a user > from explicitly saying "this subclass should not inherit any > Foo-annotations" without adding at least one new Foo-annotation on the > subclass). > > -- Andreas From andreas.lundblad at oracle.com Mon Oct 14 05:44:45 2013 From: andreas.lundblad at oracle.com (Andreas Lundblad) Date: Mon, 14 Oct 2013 14:44:45 +0200 Subject: Behavior of getAnnotationsByType for @FooContainer({}) In-Reply-To: <5258556B.3030107@oracle.com> References: <525678AA.6010007@oracle.com> <5256E822.8040607@oracle.com> <5257A806.5090502@oracle.com> <5258556B.3030107@oracle.com> Message-ID: <525BE73D.6020703@oracle.com> On 10/11/2013 09:45 PM, Alex Buckley wrote: > Hi Andreas, > > In Java SE 7, an @Foo on class A is visible on class B - class B > "bought in" to that policy when it subclassed A. And so, in SE 7, the > only way to "prevent" A's @Foo from being visible on B is for B to > have a directly-present @Foo. That doesn't change in SE 8 - we just > allow B to have one @Foo (directly-present) or many (indirectly-present). > > More generally, as a general principle, a thing is inherited unless > overridden by a thing of the same name. And so, for the new > get[Declared]AnnotationsByType methods in AnnotatedElement, we try > hard to "look through" the container annotation and reason solely > about annotations of the type which the user actually queried > (Foo.class). In this model, it's undesirable to say that @FooContainer > on B overrides @Foo on A. > > Alex > Alex, I agree that making containers as "transparent" as possible is a good idea. In this case however, I would argue that we should see through the container, but not through the empty list. Take for instance the case where idiomatic containers are used, i.e. we have @FooContainer({@Foo}) class A {} @FooContainer({}) class B extends A {} Here {} is bound to overwrite {@Foo}. If we say that @FooContainer({}) should be "ignored" (i.e. its presense should not prevent inheritence) some SE7 code may have troubles adopting the @Repeatable feature. If we, on the other hand, do take the empty list into consideration, the indirectly present annotations can still be inherited by simply leaving @FooContainer({}) out. That being said, I have only worked with this for a week or so, so please forgive me if I've overlooked something. -- Andreas From alex.buckley at oracle.com Mon Oct 14 12:09:35 2013 From: alex.buckley at oracle.com (Alex Buckley) Date: Mon, 14 Oct 2013 12:09:35 -0700 Subject: Behavior of getAnnotationsByType for @FooContainer({}) In-Reply-To: <525BE73D.6020703@oracle.com> References: <525678AA.6010007@oracle.com> <5256E822.8040607@oracle.com> <5257A806.5090502@oracle.com> <5258556B.3030107@oracle.com> <525BE73D.6020703@oracle.com> Message-ID: <525C416F.9020602@oracle.com> On 10/14/2013 5:44 AM, Andreas Lundblad wrote: > I agree that making containers as "transparent" as possible is a good > idea. In this case however, I would argue that we should see through the > container, but not through the empty list. > > Take for instance the case where idiomatic containers are used, i.e. we > have > > @FooContainer({@Foo}) class A {} > @FooContainer({}) class B extends A {} > > Here {} is bound to overwrite {@Foo}. If we say that @FooContainer({}) > should be "ignored" (i.e. its presense should not prevent inheritence) > some SE7 code may have troubles adopting the @Repeatable feature. If we, > on the other hand, do take the empty list into consideration, the > indirectly present annotations can still be inherited by simply leaving > @FooContainer({}) out. SE 7 code running on SE 8, or even recompiled on SE 8, sees no change. The way it "adopts" the @Repeatable feature is to start using get[Declared]AnnotationsByType, whose behavior is clearly documented. Whether code that starts using B.class.getAnnotationsByType(Foo.class) is "surprised" to see @Foo on B depends on the "search policy" inherent in the code, that is, the way it looks for annotations in the class hierarchy. For example, suppose SE 7 code calls B.class.getAnnotations(), sees @FooContainer({}) with its empty list, and determines there are no @Foo annotations on B. That's a reasonable search policy. Now, what if the author of A realizes there is no point using a container for only one @Foo, and rewrites A so only @Foo appears? Answer: the SE 7 code now sees @Foo on B as well as @FooContainer({}), and can presumably cope by simply using the @Foo. (We determined in 2012 that SE 7 code in frameworks can handle a base annotation side by side with a container annotation; ultimately, one expects a framework to use the @Foo rather than throw it away because of the {}. After all, the SE 7 code used getAnnotations() so is aware that superclasses can contribute @Foo's to the party.) When the SE 7 code migrates to SE 8 by using B.class.getAnnotationsByType(Foo.class), it will still see @Foo, so that's fine. If the search policy all along had been to call B.class.getDeclaredAnnotations(), then the SE 7 code would never have seen @Foo on B, regardless of the annotations on A. Migrating to B.class.getDeclaredAnnotationsByType(Foo.class) will still not expose @Foo on B, so that's fine. Bottom line, our long-term goal is to move people away from writing container annotations by hand, so embedding special treatment for "empty" container annotations into the new core reflection methods is undesirable. We have a simple model that works pretty well, and it's past time for changing it. Alex From srikanth_sankaran at in.ibm.com Mon Oct 21 05:41:43 2013 From: srikanth_sankaran at in.ibm.com (Srikanth S Adayapalam) Date: Mon, 21 Oct 2013 18:11:43 +0530 Subject: Eclipse compiler support for JEP120 & JEP118. In-Reply-To: References: Message-ID: Hello, 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 forax at univ-mlv.fr Mon Oct 21 14:35:26 2013 From: forax at univ-mlv.fr (Remi Forax) Date: Mon, 21 Oct 2013 23:35:26 +0200 Subject: Eclipse compiler support for JEP120 & JEP118. In-Reply-To: References: Message-ID: <52659E1E.3050401@univ-mlv.fr> On 10/21/2013 02:41 PM, Srikanth S Adayapalam wrote: > Hello, > > 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. Cool, How does a user specify that parameter names must be reified ? cheers, R?mi From jesper at selskabet.org Mon Oct 21 22:46:09 2013 From: jesper at selskabet.org (=?iso-8859-1?Q?Jesper_Steen_M=F8ller?=) Date: Tue, 22 Oct 2013 07:46:09 +0200 Subject: Eclipse compiler support for JEP120 & JEP118. In-Reply-To: <52659E1E.3050401@univ-mlv.fr> References: <52659E1E.3050401@univ-mlv.fr> Message-ID: Hi R?mi On 21/10/2013, at 23.35, Remi Forax wrote: > > Cool, > How does a user specify that parameter names must be reified ? > Inside Eclipse, it's on the main Java Compiler settings page, as "Preserve method parameter names" (bottommost). From the EJC command line tool, "-parameters" (like javac) In a JDT prefs file: org.eclipse.jdt.core.compiler.codegen.methodParameters=generate -Jesper From alex.buckley at oracle.com Tue Oct 22 14:16:39 2013 From: alex.buckley at oracle.com (Alex Buckley) Date: Tue, 22 Oct 2013 14:16:39 -0700 Subject: Eclipse compiler support for JEP120 & JEP118. In-Reply-To: References: Message-ID: <5266EB37.9030705@oracle.com> Thanks for this great news Srikanth! On 10/21/2013 5:41 AM, Srikanth S Adayapalam wrote: > Hello, > > 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 joe.darcy at oracle.com Thu Oct 24 00:16:26 2013 From: joe.darcy at oracle.com (Joe Darcy) Date: Thu, 24 Oct 2013 00:16:26 -0700 Subject: Proposal to make new-in-Java-SE-8 methods on AnnotatedElement default methods Message-ID: <5268C94A.8070208@oracle.com> Hello, Previously, an issue was filed to consider making the new-in-Java-SE-8 methods on AnnotatedElement default methods: JDK-8005294 Consider default methods for additions to AnnotatedElement https://bugs.openjdk.java.net/browse/JDK-8005294 I've looked into the issue and I've concluded this is a reasonable suggestion. The proposed specification change is small the implementation manageable. The diffs of the proposed specification changes are below. (Implementations changes will be reviewed by core-libs.) Note that in the reference implementation, none of the concrete implementations of AnnotatedElement would call the default methods. Instead, those methods are instead implemented to take advantage of lower-level implementation data structures. Changing the new methods to be default methods would allow any implementations of AnnotatedElement outside of the reference implementation to behave reasonably under Java SE 8. Thanks, -Joe + * @implSpec The default implementation first calls {@link + * #getAnnotation(Class)} on the argument type. If the annotation + * is directly or indirectly present, it is returned in an + * one-element array. Otherwise, if the argument annotation type + * is repeatable and an annotation of the container type is + * directly or indirectly present, then the returned result is + * equal to the result of calling the {@code value} method on the + * container annotation. + * * @param the type of the annotation to query for and return if present * @param annotationClass the Class object corresponding to the * annotation type @@ -230,8 +241,10 @@ * @throws NullPointerException if the given annotation class is null * @since 1.8 */ - T[] getAnnotationsByType(Class annotationClass); + default T[] getAnnotationsByType(Class annotationClass) { + * @implSpec The default implementation first calls {@link + * #getDeclaredAnnotation(Class)} on the argument type. If the + * annotation is directly present, it is returned in an + * one-element array. Otherwise, if the argument annotation type + * is repeatable and an annotation of the container type is + * directly present, then the returned result is equal to the + * result of calling the {@code value} method on the container + * annotation. + * * @param the type of the annotation to query for and return * if directly or indirectly present * @param annotationClass the Class object corresponding to the @@ -277,7 +315,9 @@ * @throws NullPointerException if the given annotation class is null * @since 1.8 */ - T[] getDeclaredAnnotationsByType(Class annotationClass); + default T[] getDeclaredAnnotationsByType(Class annotationClass) { + * @implSpec The default implementation first performs a null check + * and then loops over the results of {@link + * getDeclaredAnnotations} returning the first annotation whose + * annotation type matches the argument type. + * * @param the type of the annotation to query for and return if directly present * @param annotationClass the Class object corresponding to the * annotation type @@ -247,7 +265,18 @@ * @throws NullPointerException if the given annotation class is null * @since 1.8 */ - T getDeclaredAnnotation(Class annotationClass); + default T getDeclaredAnnotation(Class annotationClass) { From elena.votchennikova at oracle.com Thu Oct 24 07:37:13 2013 From: elena.votchennikova at oracle.com (elena votchennikova) Date: Thu, 24 Oct 2013 18:37:13 +0400 Subject: j.l.r.Parameter.hashCode() question In-Reply-To: <524EF784.4090706@oracle.com> References: <524AD426.7000702@oracle.com> <524E13EA.3040406@oracle.com> <524E9D28.8060305@oracle.com> <524EF784.4090706@oracle.com> Message-ID: <52693099.8070908@oracle.com> Hello Joe, On 04.10.2013 21:14, Joe Darcy wrote: > Hello Elena, > > On 10/04/2013 03:49 AM, elena votchennikova wrote: >> Hi Joe, >> >> thank you for the replay, >> >> On 04.10.2013 5:03, Joseph Darcy wrote: >>> Hello Elena, >>> >>> The general requirements from Object.hashCode hold: equal objects >>> must have equal hash codes. (Of necessity, unequal objects may have >>> the same hash code.) >> Yep. >>> >>> The phrased "based on" means "some unspecified function of." It is >>> generally undesirable to exactly specify a hash code function when >>> you don't absolutely have to. >> So, do you mean that the executable and the index are just used in >> this "unspecified function" or do you want to say that if the >> executable and the index are same, then the hash codes will be the same? >> >> I just want to clarify it, because if the answer is "yes" then I >> think this is not obviously from the wording "based on". And if the >> answer is "no", that this is Ok. >> But in the spec to the equals() method we have the same wording: >> "Compares based on the executable and the index.". But what does this >> exactly mean? >> >> >> Thank you for your help, >> Elena > > It it implicit that the hashCode and equals mehtods on Parameter > follow the general hashCode and equals contract. > > Equality is based on executable and index; I don't think it is helpful > to write specification that is equivalent to the implementation of > > if(obj instanceof Parameter) { > Parameter other = (Parameter)obj; > return (other.executable.equals(executable) && > other.index == index); > } > return false; I think this is not obvious from the words "Compares based on the executable and the index" that Parameters are equals if "other.executable.equals(executable) && other.index == index". If you mean exactly such check, it will be better to make the documentation more strong and mention this somehow. Because different implementations could weaken this contract and interpret this differently. Would it be Ok? What do you think about it? > > We do not want to specify the hash function; it is sufficient to say > it takes the executable and index as inputs. Sounds reasonable. Thank you a lot, Elena > > Cheers, > > -Joe From joel.franck at oracle.com Thu Oct 24 08:34:02 2013 From: joel.franck at oracle.com (=?windows-1252?Q?Joel_Borggr=E9n-Franck?=) Date: Thu, 24 Oct 2013 23:34:02 +0800 Subject: Proposal to make new-in-Java-SE-8 methods on AnnotatedElement default methods In-Reply-To: <5268C94A.8070208@oracle.com> References: <5268C94A.8070208@oracle.com> Message-ID: <3677C436-B2C2-44D5-A2F7-EC46ED1AB301@oracle.com> Hi Joe, I agree this would be nice to do, but see comments inline, On 24 okt 2013, at 15:16, Joe Darcy wrote: > > > + * @implSpec The default implementation first calls {@link > + * #getAnnotation(Class)} on the argument type. If the annotation > + * is directly or indirectly present, it is returned in an > + * one-element array. Otherwise, if the argument annotation type > + * is repeatable and an annotation of the container type is > + * directly or indirectly present, then the returned result is > + * equal to the result of calling the {@code value} method on the > + * container annotation. > + * > * @param the type of the annotation to query for and return if present > * @param annotationClass the Class object corresponding to the > * annotation type > @@ -230,8 +241,10 @@ > * @throws NullPointerException if the given annotation class is null > * @since 1.8 > */ > - T[] getAnnotationsByType(Class annotationClass); > + default T[] getAnnotationsByType(Class annotationClass) { > This is the wrong order. The precise lookup of an associated annotation is declared then inherited, quoting the javadoc for AnnotatedElement: "? An annotation A is associated with an element E if either: ? A is directly or indirectly present on E; or ? No annotation of A 's type is directly or indirectly present on E, and E is a class, and A's type is inheritable, and A is associated with the superclass of E." > > + * @implSpec The default implementation first calls {@link > + * #getDeclaredAnnotation(Class)} on the argument type. If the > + * annotation is directly present, it is returned in an > + * one-element array. Otherwise, if the argument annotation type > + * is repeatable and an annotation of the container type is > + * directly present, then the returned result is equal to the > + * result of calling the {@code value} method on the container > + * annotation. > + * > * @param the type of the annotation to query for and return > * if directly or indirectly present > * @param annotationClass the Class object corresponding to the > @@ -277,7 +315,9 @@ > * @throws NullPointerException if the given annotation class is null > * @since 1.8 > */ > - T[] getDeclaredAnnotationsByType(Class annotationClass); > + default T[] getDeclaredAnnotationsByType(Class annotationClass) { > This should work. > > + * @implSpec The default implementation first performs a null check > + * and then loops over the results of {@link > + * getDeclaredAnnotations} returning the first annotation whose > + * annotation type matches the argument type. > + * > * @param the type of the annotation to query for and return if directly present > * @param annotationClass the Class object corresponding to the > * annotation type > @@ -247,7 +265,18 @@ > * @throws NullPointerException if the given annotation class is null > * @since 1.8 > */ > - T getDeclaredAnnotation(Class annotationClass); > + default T getDeclaredAnnotation(Class annotationClass) { > Wouldn't this risk the same issues as when we turned isAnnotationPresent() into a default? cheers /Joel From alex.buckley at oracle.com Thu Oct 24 11:37:15 2013 From: alex.buckley at oracle.com (Alex Buckley) Date: Thu, 24 Oct 2013 11:37:15 -0700 Subject: Proposal to make new-in-Java-SE-8 methods on AnnotatedElement default methods In-Reply-To: <3677C436-B2C2-44D5-A2F7-EC46ED1AB301@oracle.com> References: <5268C94A.8070208@oracle.com> <3677C436-B2C2-44D5-A2F7-EC46ED1AB301@oracle.com> Message-ID: <526968DB.2070806@oracle.com> On 10/24/2013 8:34 AM, Joel Borggr?n-Franck wrote: > On 24 okt 2013, at 15:16, Joe Darcy wrote: >> >> >> + * @implSpec The default implementation first calls {@link >> + * #getAnnotation(Class)} on the argument type. If the annotation >> + * is directly or indirectly present, it is returned in an >> + * one-element array. Otherwise, if the argument annotation type >> + * is repeatable and an annotation of the container type is >> + * directly or indirectly present, then the returned result is >> + * equal to the result of calling the {@code value} method on the >> + * container annotation. ... >> - T[] getAnnotationsByType(Class annotationClass); >> + default T[] getAnnotationsByType(Class annotationClass) { >> > > This is the wrong order. The precise lookup of an associated annotation is declared then inherited, quoting the javadoc for AnnotatedElement: Yes, and the root cause is an inconsistency in the @implSpec. The first call to getAnnotation(Class) will tell you if an annotation is _present_, which is not the same thing as "directly or indirectly present". In fact, as a legacy method, getAnnotation(Class) will never reveal an indirectly present annotation. The @implSpec should say "If an annotation of type T is present, it is included in the returned array. [If multiple annotations of type T are present because someone made a Runtime*Annotations attribute with @Foo @Foo by hand, then the first is chosen.]" There's a bigger problem: the word "Otherwise". The intent of getAnnotationsByType(Class) is to expose the directly present annotation (if any) _and_ indirectly present annotations as may be found in a container annotation. This is Example 1.2-3 in 8misc.pdf, where an @Foo and an @FooContainer are side by side on an element. Returning a one-element array can't be right. >> + * @implSpec The default implementation first calls {@link >> + * #getDeclaredAnnotation(Class)} on the argument type. If the >> + * annotation is directly present, it is returned in an >> + * one-element array. Otherwise, if the argument annotation type >> + * is repeatable and an annotation of the container type is >> + * directly present, then the returned result is equal to the >> + * result of calling the {@code value} method on the container >> + * annotation. >> + * >> * @param the type of the annotation to query for and return >> * if directly or indirectly present >> * @param annotationClass the Class object corresponding to the >> @@ -277,7 +315,9 @@ >> * @throws NullPointerException if the given annotation class is null >> * @since 1.8 >> */ >> - T[] getDeclaredAnnotationsByType(Class annotationClass); >> + default T[] getDeclaredAnnotationsByType(Class annotationClass) { >> > > This should work. In a similar fashion to above, the intent of getDeclaredAnnotationsByType(Class) is to reveal all directly and indirectly present annotations, not just one directly present annotation. >> + * @implSpec The default implementation first performs a null check >> + * and then loops over the results of {@link >> + * getDeclaredAnnotations} returning the first annotation whose >> + * annotation type matches the argument type. >> + * >> * @param the type of the annotation to query for and return if directly present >> * @param annotationClass the Class object corresponding to the >> * annotation type >> @@ -247,7 +265,18 @@ >> * @throws NullPointerException if the given annotation class is null >> * @since 1.8 >> */ >> - T getDeclaredAnnotation(Class annotationClass); >> + default T getDeclaredAnnotation(Class annotationClass) { >> > > Wouldn't this risk the same issues as when we turned isAnnotationPresent() into a default? The spec is correct though :-) Alex From joe.darcy at oracle.com Thu Oct 24 19:08:05 2013 From: joe.darcy at oracle.com (Joe Darcy) Date: Thu, 24 Oct 2013 19:08:05 -0700 Subject: Proposal to make new-in-Java-SE-8 methods on AnnotatedElement default methods In-Reply-To: <3677C436-B2C2-44D5-A2F7-EC46ED1AB301@oracle.com> References: <5268C94A.8070208@oracle.com> <3677C436-B2C2-44D5-A2F7-EC46ED1AB301@oracle.com> Message-ID: <5269D285.7070002@oracle.com> Hi Joel, Reponding to point question below... On 10/24/2013 08:34 AM, Joel Borggr?n-Franck wrote: > Hi Joe, > > I agree this would be nice to do, but see comments inline, > > On 24 okt 2013, at 15:16, Joe Darcy wrote: >> >> + * @implSpec The default implementation first calls {@link >> + * #getAnnotation(Class)} on the argument type. If the annotation >> + * is directly or indirectly present, it is returned in an >> + * one-element array. Otherwise, if the argument annotation type >> + * is repeatable and an annotation of the container type is >> + * directly or indirectly present, then the returned result is >> + * equal to the result of calling the {@code value} method on the >> + * container annotation. >> + * >> * @param the type of the annotation to query for and return if present >> * @param annotationClass the Class object corresponding to the >> * annotation type >> @@ -230,8 +241,10 @@ >> * @throws NullPointerException if the given annotation class is null >> * @since 1.8 >> */ >> - T[] getAnnotationsByType(Class annotationClass); >> + default T[] getAnnotationsByType(Class annotationClass) { >> > This is the wrong order. The precise lookup of an associated annotation is declared then inherited, quoting the javadoc for AnnotatedElement: > > "? An annotation A is associated with an element E if either: > ? A is directly or indirectly present on E; or > ? No annotation of A 's type is directly or indirectly present on E, and E is a class, and A's type is inheritable, and A is associated with the superclass of E." > >> + * @implSpec The default implementation first calls {@link >> + * #getDeclaredAnnotation(Class)} on the argument type. If the >> + * annotation is directly present, it is returned in an >> + * one-element array. Otherwise, if the argument annotation type >> + * is repeatable and an annotation of the container type is >> + * directly present, then the returned result is equal to the >> + * result of calling the {@code value} method on the container >> + * annotation. >> + * >> * @param the type of the annotation to query for and return >> * if directly or indirectly present >> * @param annotationClass the Class object corresponding to the >> @@ -277,7 +315,9 @@ >> * @throws NullPointerException if the given annotation class is null >> * @since 1.8 >> */ >> - T[] getDeclaredAnnotationsByType(Class annotationClass); >> + default T[] getDeclaredAnnotationsByType(Class annotationClass) { >> > This should work. > >> + * @implSpec The default implementation first performs a null check >> + * and then loops over the results of {@link >> + * getDeclaredAnnotations} returning the first annotation whose >> + * annotation type matches the argument type. >> + * >> * @param the type of the annotation to query for and return if directly present >> * @param annotationClass the Class object corresponding to the >> * annotation type >> @@ -247,7 +265,18 @@ >> * @throws NullPointerException if the given annotation class is null >> * @since 1.8 >> */ >> - T getDeclaredAnnotation(Class annotationClass); >> + default T getDeclaredAnnotation(Class annotationClass) { >> > Wouldn't this risk the same issues as when we turned isAnnotationPresent() into a default? > > No; we don't have the same hazard here as with isAnnotationPresent. The issue we ran into with making isAnnotationPresent a default method was that isAnnotationPresent was part of the original AnnotatedElement interface defined way back in Java SE 5. In implementation decision in javac did not expose the existence of default methods to code being compiled under source levels less than 8. That is a pragmatic choice and usually gives the desired result, but not in this case. Making the new-in-Java-SE-8 methods in AnnotatedElement defaults follows the generally recommended way to evolve interfaces when new methods are added to them. Thanks for the comments; I'll get to work fixing the implementation, -Joe From joe.darcy at oracle.com Fri Oct 25 01:35:31 2013 From: joe.darcy at oracle.com (Joe Darcy) Date: Fri, 25 Oct 2013 01:35:31 -0700 Subject: Proposal to make new-in-Java-SE-8 methods on AnnotatedElement default methods In-Reply-To: <526968DB.2070806@oracle.com> References: <5268C94A.8070208@oracle.com> <3677C436-B2C2-44D5-A2F7-EC46ED1AB301@oracle.com> <526968DB.2070806@oracle.com> Message-ID: <526A2D53.8080309@oracle.com> Hello, Second iterations of @implSpec's for get[Declared]AnnotationsByType interspersed below: On 10/24/2013 11:37 AM, Alex Buckley wrote: > On 10/24/2013 8:34 AM, Joel Borggr?n-Franck wrote: >> On 24 okt 2013, at 15:16, Joe Darcy wrote: >>> >>> >>> + * @implSpec The default implementation first calls {@link >>> + * #getAnnotation(Class)} on the argument type. If the annotation >>> + * is directly or indirectly present, it is returned in an >>> + * one-element array. Otherwise, if the argument annotation type >>> + * is repeatable and an annotation of the container type is >>> + * directly or indirectly present, then the returned result is >>> + * equal to the result of calling the {@code value} method on the >>> + * container annotation. > ... >>> - T[] getAnnotationsByType(Class >>> annotationClass); >>> + default T[] >>> getAnnotationsByType(Class annotationClass) { >>> >> >> This is the wrong order. The precise lookup of an associated >> annotation is declared then inherited, quoting the javadoc for >> AnnotatedElement: > > Yes, and the root cause is an inconsistency in the @implSpec. The > first call to getAnnotation(Class) will tell you if an annotation is > _present_, which is not the same thing as "directly or indirectly > present". In fact, as a legacy method, getAnnotation(Class) will never > reveal an indirectly present annotation. The @implSpec should say "If > an annotation of type T is present, it is included in the returned > array. [If multiple annotations of type T are present because someone > made a Runtime*Annotations attribute with @Foo @Foo by hand, then the > first is chosen.]" > > There's a bigger problem: the word "Otherwise". The intent of > getAnnotationsByType(Class) is to expose the directly present > annotation (if any) _and_ indirectly present annotations as may be > found in a container annotation. This is Example 1.2-3 in 8misc.pdf, > where an @Foo and an @FooContainer are side by side on an element. > Returning a one-element array can't be right. Second iteration for the default method aspects of getAnnotationsByType: + * @implSpec The default implementation first calls {@link + * #getDeclaredAnnotationsByType(Class)} on the argument type. If + * the returned array has size greater than zero, the array is + * returned. If the returned array has size zero and this {@code + * AnnotatedElement} is a class and the argument type is an + * inheritable annotation, and the superclass of this {@code + * AnnoatedElement} is non-null, then the result of {@code + * getAnnotationsByType(annotationClass)} on the superclass is + * returned. Otherwise, a zero-length array is returned. + * > >>> + * @implSpec The default implementation first calls {@link >>> + * #getDeclaredAnnotation(Class)} on the argument type. If the >>> + * annotation is directly present, it is returned in an >>> + * one-element array. Otherwise, if the argument annotation type >>> + * is repeatable and an annotation of the container type is >>> + * directly present, then the returned result is equal to the >>> + * result of calling the {@code value} method on the container >>> + * annotation. >>> + * >>> * @param the type of the annotation to query for and return >>> * if directly or indirectly present >>> * @param annotationClass the Class object corresponding to the >>> @@ -277,7 +315,9 @@ >>> * @throws NullPointerException if the given annotation class >>> is null >>> * @since 1.8 >>> */ >>> - T[] >>> getDeclaredAnnotationsByType(Class annotationClass); >>> + default T[] >>> getDeclaredAnnotationsByType(Class annotationClass) { >>> >> >> This should work. > > In a similar fashion to above, the intent of > getDeclaredAnnotationsByType(Class) is to reveal all directly and > indirectly present annotations, not just one directly present annotation. Second iteration for the default method aspects of getDeclaredAnnotationsByType: + * @implSpec The default implementation may call {@link + * #getDeclaredAnnotation(Class)} one or more times to find a + * directly present annotation and, if the annotation type is + * repeatable, to find a container annotation. If the annotation + * type is both directly and indirectly present, {@link + * getDeclaredAnnotations()} will get called to determine the + * order of the elements in the returned array. Alternatively, + * {@link getDeclaredAnnotations()} may be called a single time + * and the returned array examined for both directly and + * indirectly present annotations. The results of calling {@link + * getDeclaredAnnotations()} are assumed to be consistent with the + * results of calling {@code #getDeclaredAnnotation} Thanks, -Joe From joe.darcy at oracle.com Fri Oct 25 10:11:27 2013 From: joe.darcy at oracle.com (Joe Darcy) Date: Fri, 25 Oct 2013 10:11:27 -0700 Subject: j.l.r.Parameter.hashCode() question In-Reply-To: <52693099.8070908@oracle.com> References: <524AD426.7000702@oracle.com> <524E13EA.3040406@oracle.com> <524E9D28.8060305@oracle.com> <524EF784.4090706@oracle.com> <52693099.8070908@oracle.com> Message-ID: <526AA63F.5010506@oracle.com> Hello Elena, On 10/24/2013 07:37 AM, elena votchennikova wrote: > Hello Joe, > > On 04.10.2013 21:14, Joe Darcy wrote: >> Hello Elena, >> >> On 10/04/2013 03:49 AM, elena votchennikova wrote: >>> Hi Joe, >>> >>> thank you for the replay, >>> >>> On 04.10.2013 5:03, Joseph Darcy wrote: >>>> Hello Elena, >>>> >>>> The general requirements from Object.hashCode hold: equal objects >>>> must have equal hash codes. (Of necessity, unequal objects may have >>>> the same hash code.) >>> Yep. >>>> >>>> The phrased "based on" means "some unspecified function of." It is >>>> generally undesirable to exactly specify a hash code function when >>>> you don't absolutely have to. >>> So, do you mean that the executable and the index are just used in >>> this "unspecified function" or do you want to say that if the >>> executable and the index are same, then the hash codes will be the >>> same? >>> >>> I just want to clarify it, because if the answer is "yes" then I >>> think this is not obviously from the wording "based on". And if the >>> answer is "no", that this is Ok. >>> But in the spec to the equals() method we have the same wording: >>> "Compares based on the executable and the index.". But what does >>> this exactly mean? >>> >>> >>> Thank you for your help, >>> Elena >> >> It it implicit that the hashCode and equals mehtods on Parameter >> follow the general hashCode and equals contract. >> >> Equality is based on executable and index; I don't think it is >> helpful to write specification that is equivalent to the >> implementation of >> >> if(obj instanceof Parameter) { >> Parameter other = (Parameter)obj; >> return (other.executable.equals(executable) && >> other.index == index); >> } >> return false; > I think this is not obvious from the words "Compares based on the > executable and the index" that Parameters are equals if > "other.executable.equals(executable) && other.index == index". > If you mean exactly such check, it will be better to make the > documentation more strong and mention this somehow. Because different > implementations could weaken this contract and interpret this > differently. Would it be Ok? > What do you think about it? > I don't really see how the equals contract saying "Compares based on the executable and the index" could lead a reasonable programmer to code up something that was not equivalent to "other.executable.equals(executable) && other.index == index". I don't intend to adjust the current specification. Cheers, -Joe From elena.votchennikova at oracle.com Mon Oct 28 08:55:20 2013 From: elena.votchennikova at oracle.com (elena votchennikova) Date: Mon, 28 Oct 2013 19:55:20 +0400 Subject: j.l.r.Parameter.hashCode() question In-Reply-To: <526AA63F.5010506@oracle.com> References: <524AD426.7000702@oracle.com> <524E13EA.3040406@oracle.com> <524E9D28.8060305@oracle.com> <524EF784.4090706@oracle.com> <52693099.8070908@oracle.com> <526AA63F.5010506@oracle.com> Message-ID: <526E88E8.2080302@oracle.com> Hello Joe, On 25.10.2013 21:11, Joe Darcy wrote: > >> >>>> On 04.10.2013 5:03, Joseph Darcy wrote: >>>>> The phrased "based on" means "some unspecified function of." >>>> >>> >> > I don't really see how the equals contract saying "Compares based on > the executable and the index" could lead a reasonable programmer to > code up something that was not equivalent to > "other.executable.equals(executable) && other.index == index". > "Compares based on the executable and the index" means someFunction(Executable executable, int index, ???) I cannot say nothing about the implementation of this "someFunction". Elena From forax at univ-mlv.fr Mon Oct 28 09:20:50 2013 From: forax at univ-mlv.fr (Remi Forax) Date: Mon, 28 Oct 2013 17:20:50 +0100 Subject: j.l.r.Parameter.hashCode() question In-Reply-To: <526E88E8.2080302@oracle.com> References: <524AD426.7000702@oracle.com> <524E13EA.3040406@oracle.com> <524E9D28.8060305@oracle.com> <524EF784.4090706@oracle.com> <52693099.8070908@oracle.com> <526AA63F.5010506@oracle.com> <526E88E8.2080302@oracle.com> Message-ID: <526E8EE2.8060306@univ-mlv.fr> On 10/28/2013 04:55 PM, elena votchennikova wrote: > Hello Joe, > > On 25.10.2013 21:11, Joe Darcy wrote: >> >>> >>>>> On 04.10.2013 5:03, Joseph Darcy wrote: >>>>>> The phrased "based on" means "some unspecified function of." >>>>> >>>> >>> >> I don't really see how the equals contract saying "Compares based on >> the executable and the index" could lead a reasonable programmer to >> code up something that was not equivalent to >> "other.executable.equals(executable) && other.index == index". >> > > "Compares based on the executable and the index" means > someFunction(Executable executable, int index, ???) yes. > > I cannot say nothing about the implementation of this "someFunction". yes, that's the idea, someFunction is a black box. > > > Elena R?mi From joe.darcy at oracle.com Mon Oct 28 09:41:27 2013 From: joe.darcy at oracle.com (Joe Darcy) Date: Mon, 28 Oct 2013 09:41:27 -0700 Subject: j.l.r.Parameter.hashCode() question In-Reply-To: <526E88E8.2080302@oracle.com> References: <524AD426.7000702@oracle.com> <524E13EA.3040406@oracle.com> <524E9D28.8060305@oracle.com> <524EF784.4090706@oracle.com> <52693099.8070908@oracle.com> <526AA63F.5010506@oracle.com> <526E88E8.2080302@oracle.com> Message-ID: <526E93B7.4050300@oracle.com> On 10/28/2013 08:55 AM, elena votchennikova wrote: > Hello Joe, > > On 25.10.2013 21:11, Joe Darcy wrote: >> >>> >>>>> On 04.10.2013 5:03, Joseph Darcy wrote: >>>>>> The phrased "based on" means "some unspecified function of." >>>>> >>>> >>> >> I don't really see how the equals contract saying "Compares based on >> the executable and the index" could lead a reasonable programmer to >> code up something that was not equivalent to >> "other.executable.equals(executable) && other.index == index". >> > > "Compares based on the executable and the index" means > someFunction(Executable executable, int index, ???) > > I cannot say nothing about the implementation of this "someFunction". > > If on an exam you were posed the question: "Equality for the Parameter class compares on the executable and the index. Write an equals method for the Parameter class that satisfies the general equals contract." and you answer did not include something like ... return this.executable.equals(that.executable) && this.index == that.index your answer would be marked wrong. There is no other way to satisfy the constraints of the problem. -Joe From alex.buckley at oracle.com Mon Oct 28 10:19:24 2013 From: alex.buckley at oracle.com (Alex Buckley) Date: Mon, 28 Oct 2013 10:19:24 -0700 Subject: Proposal to make new-in-Java-SE-8 methods on AnnotatedElement default methods In-Reply-To: <526A2D53.8080309@oracle.com> References: <5268C94A.8070208@oracle.com> <3677C436-B2C2-44D5-A2F7-EC46ED1AB301@oracle.com> <526968DB.2070806@oracle.com> <526A2D53.8080309@oracle.com> Message-ID: <526E9C9C.50904@oracle.com> Semantics look good; some wording concerns below. On 10/25/2013 1:35 AM, Joe Darcy wrote: > Second iteration for the default method aspects of getAnnotationsByType: > > + * @implSpec The default implementation first calls {@link > + * #getDeclaredAnnotationsByType(Class)} on the argument type. If > + * the returned array has size greater than zero, the array is > + * returned. If the returned array has size zero and this {@code > + * AnnotatedElement} is a class and the argument type is an > + * inheritable annotation, and the superclass of this {@code > + * AnnoatedElement} is non-null, then the result of {@code > + * getAnnotationsByType(annotationClass)} on the superclass is > + * returned. Otherwise, a zero-length array is returned. "calls getDeclaredAnnotationsByType(Class) on the argument type" can be read as "executes annotationClass.getDeclaredAnnotationsByType(Class)" - that's how you use "on" in the penultimate sentence. Generally "argument type" is problematic - the type Class is not especially interesting here. Try "calls getDeclaredAnnotationsByType(Class) passing the annotationClass argument." "and annotationClass represents an inheritable annotation _type_, and ..." "then the result of calling getAnnotationsByType(Class) on the superclass, _once again passing annotationClass,_ is returned." > Second iteration for the default method aspects of > getDeclaredAnnotationsByType: > > + * @implSpec The default implementation may call {@link > + * #getDeclaredAnnotation(Class)} one or more times to find a > + * directly present annotation and, if the annotation type is > + * repeatable, to find a container annotation. If the annotation > + * type is both directly and indirectly present, {@link > + * getDeclaredAnnotations()} will get called to determine the > + * order of the elements in the returned array. Alternatively, > + * {@link getDeclaredAnnotations()} may be called a single time > + * and the returned array examined for both directly and > + * indirectly present annotations. The results of calling {@link > + * getDeclaredAnnotations()} are assumed to be consistent with the > + * results of calling {@code #getDeclaredAnnotation} "If the annotation type is both directly and indirectly present" - annotations, not their types, are directly/indirectly present. Try "If annotations of type annotationClass are determined to be directly present and indirectly present, then getDeclaredAnnotations() is called to determine the order ..." I think the middle part should read "Alternatively, the default implementation may call ..." because otherwise the remainder of the @implSpec is too easily read as a sub-clause of of determining the order of elements in the returned array. Need a (Class) in the final @code. Alex From joe.darcy at oracle.com Mon Oct 28 18:22:16 2013 From: joe.darcy at oracle.com (Joe Darcy) Date: Mon, 28 Oct 2013 18:22:16 -0700 Subject: Proposal to make new-in-Java-SE-8 methods on AnnotatedElement default methods In-Reply-To: <526E9C9C.50904@oracle.com> References: <5268C94A.8070208@oracle.com> <3677C436-B2C2-44D5-A2F7-EC46ED1AB301@oracle.com> <526968DB.2070806@oracle.com> <526A2D53.8080309@oracle.com> <526E9C9C.50904@oracle.com> Message-ID: <526F0DC8.7030809@oracle.com> Hi Alex, On 10/28/2013 10:19 AM, Alex Buckley wrote: > Semantics look good; some wording concerns below. > > On 10/25/2013 1:35 AM, Joe Darcy wrote: >> Second iteration for the default method aspects of getAnnotationsByType: >> >> + * @implSpec The default implementation first calls {@link >> + * #getDeclaredAnnotationsByType(Class)} on the argument type. If >> + * the returned array has size greater than zero, the array is >> + * returned. If the returned array has size zero and this {@code >> + * AnnotatedElement} is a class and the argument type is an >> + * inheritable annotation, and the superclass of this {@code >> + * AnnoatedElement} is non-null, then the result of {@code >> + * getAnnotationsByType(annotationClass)} on the superclass is >> + * returned. Otherwise, a zero-length array is returned. > > "calls getDeclaredAnnotationsByType(Class) on the argument type" can > be read as "executes > annotationClass.getDeclaredAnnotationsByType(Class)" - that's how you > use "on" in the penultimate sentence. Generally "argument type" is > problematic - the type Class is not especially interesting here. > Try "calls getDeclaredAnnotationsByType(Class) passing the > annotationClass argument." > > "and annotationClass represents an inheritable annotation _type_, and > ..." > > "then the result of calling getAnnotationsByType(Class) on the > superclass, _once again passing annotationClass,_ is returned." Changed to: + * @implSpec The default implementation first calls {@link + * #getDeclaredAnnotationsByType(Class)} passing {@code + * annotationClass} as the argument. If the returned array has + * size greater than zero, the array is returned. If the returned + * array has size zero and this {@code AnnotatedElement} is a + * class and the argument type is an inheritable annotation type, + * and the superclass of this {@code AnnoatedElement} is non-null, + * then the returned result is the result of calling {@code + * getAnnotationsByType} on the superclass with {@code + * annotationClass} as the argument. Otherwise, a zero-length + * array is returned. + * > >> Second iteration for the default method aspects of >> getDeclaredAnnotationsByType: >> >> + * @implSpec The default implementation may call {@link >> + * #getDeclaredAnnotation(Class)} one or more times to find a >> + * directly present annotation and, if the annotation type is >> + * repeatable, to find a container annotation. If the annotation >> + * type is both directly and indirectly present, {@link >> + * getDeclaredAnnotations()} will get called to determine the >> + * order of the elements in the returned array. Alternatively, >> + * {@link getDeclaredAnnotations()} may be called a single time >> + * and the returned array examined for both directly and >> + * indirectly present annotations. The results of calling {@link >> + * getDeclaredAnnotations()} are assumed to be consistent with the >> + * results of calling {@code #getDeclaredAnnotation} > > "If the annotation type is both directly and indirectly present" - > annotations, not their types, are directly/indirectly present. Try "If > annotations of type annotationClass are determined to be directly > present and indirectly present, then getDeclaredAnnotations() is > called to determine the order ..." > > I think the middle part should read "Alternatively, the default > implementation may call ..." because otherwise the remainder of the > @implSpec is too easily read as a sub-clause of of determining the > order of elements in the returned array. > > Need a (Class) in the final @code. > > Changed to: + * @implSpec The default implementation may call {@link + * #getDeclaredAnnotation(Class)} one or more times to find a + * directly present annotation and, if the annotation type is + * repeatable, to find a container annotation. If annotations of + * the annotation type {@code annotationClass} are found to be both + * directly and indirectly present, then {@link + * #getDeclaredAnnotations()} will get called to determine the + * order of the elements in the returned array. + * + *

Alternatively, the default implementation may call {@link + * #getDeclaredAnnotations()} a single time and the returned array + * examined for both directly and indirectly present + * annotations. The results of calling {@link + * #getDeclaredAnnotations()} are assumed to be consistent with the + * results of calling {@link #getDeclaredAnnotation(Class)}. + * Thanks, -Joe From alex.buckley at oracle.com Wed Oct 30 11:50:05 2013 From: alex.buckley at oracle.com (Alex Buckley) Date: Wed, 30 Oct 2013 11:50:05 -0700 Subject: Proposal to make new-in-Java-SE-8 methods on AnnotatedElement default methods In-Reply-To: <526F0DC8.7030809@oracle.com> References: <5268C94A.8070208@oracle.com> <3677C436-B2C2-44D5-A2F7-EC46ED1AB301@oracle.com> <526968DB.2070806@oracle.com> <526A2D53.8080309@oracle.com> <526E9C9C.50904@oracle.com> <526F0DC8.7030809@oracle.com> Message-ID: <527154DD.4090702@oracle.com> spelling: AnnoatedElement Consider mentioning only the 'length' of an array, never its 'size' (or at least use the same term within a single @implSpec). There's a {@code getAnnotationsByType} which is missing its (Class). Alex On 10/28/2013 6:22 PM, Joe Darcy wrote: > Hi Alex, > > On 10/28/2013 10:19 AM, Alex Buckley wrote: >> Semantics look good; some wording concerns below. >> >> On 10/25/2013 1:35 AM, Joe Darcy wrote: >>> Second iteration for the default method aspects of getAnnotationsByType: >>> >>> + * @implSpec The default implementation first calls {@link >>> + * #getDeclaredAnnotationsByType(Class)} on the argument type. If >>> + * the returned array has size greater than zero, the array is >>> + * returned. If the returned array has size zero and this {@code >>> + * AnnotatedElement} is a class and the argument type is an >>> + * inheritable annotation, and the superclass of this {@code >>> + * AnnoatedElement} is non-null, then the result of {@code >>> + * getAnnotationsByType(annotationClass)} on the superclass is >>> + * returned. Otherwise, a zero-length array is returned. >> >> "calls getDeclaredAnnotationsByType(Class) on the argument type" can >> be read as "executes >> annotationClass.getDeclaredAnnotationsByType(Class)" - that's how you >> use "on" in the penultimate sentence. Generally "argument type" is >> problematic - the type Class is not especially interesting here. >> Try "calls getDeclaredAnnotationsByType(Class) passing the >> annotationClass argument." >> >> "and annotationClass represents an inheritable annotation _type_, and >> ..." >> >> "then the result of calling getAnnotationsByType(Class) on the >> superclass, _once again passing annotationClass,_ is returned." > > Changed to: > > + * @implSpec The default implementation first calls {@link > + * #getDeclaredAnnotationsByType(Class)} passing {@code > + * annotationClass} as the argument. If the returned array has > + * size greater than zero, the array is returned. If the returned > + * array has size zero and this {@code AnnotatedElement} is a > + * class and the argument type is an inheritable annotation type, > + * and the superclass of this {@code AnnoatedElement} is non-null, > + * then the returned result is the result of calling {@code > + * getAnnotationsByType} on the superclass with {@code > + * annotationClass} as the argument. Otherwise, a zero-length > + * array is returned. > + * > >> >>> Second iteration for the default method aspects of >>> getDeclaredAnnotationsByType: >>> >>> + * @implSpec The default implementation may call {@link >>> + * #getDeclaredAnnotation(Class)} one or more times to find a >>> + * directly present annotation and, if the annotation type is >>> + * repeatable, to find a container annotation. If the annotation >>> + * type is both directly and indirectly present, {@link >>> + * getDeclaredAnnotations()} will get called to determine the >>> + * order of the elements in the returned array. Alternatively, >>> + * {@link getDeclaredAnnotations()} may be called a single time >>> + * and the returned array examined for both directly and >>> + * indirectly present annotations. The results of calling {@link >>> + * getDeclaredAnnotations()} are assumed to be consistent with the >>> + * results of calling {@code #getDeclaredAnnotation} >> >> "If the annotation type is both directly and indirectly present" - >> annotations, not their types, are directly/indirectly present. Try "If >> annotations of type annotationClass are determined to be directly >> present and indirectly present, then getDeclaredAnnotations() is >> called to determine the order ..." >> >> I think the middle part should read "Alternatively, the default >> implementation may call ..." because otherwise the remainder of the >> @implSpec is too easily read as a sub-clause of of determining the >> order of elements in the returned array. >> >> Need a (Class) in the final @code. >> >> > > Changed to: > > + * @implSpec The default implementation may call {@link > + * #getDeclaredAnnotation(Class)} one or more times to find a > + * directly present annotation and, if the annotation type is > + * repeatable, to find a container annotation. If annotations of > + * the annotation type {@code annotationClass} are found to be both > + * directly and indirectly present, then {@link > + * #getDeclaredAnnotations()} will get called to determine the > + * order of the elements in the returned array. > + * > + *

Alternatively, the default implementation may call {@link > + * #getDeclaredAnnotations()} a single time and the returned array > + * examined for both directly and indirectly present > + * annotations. The results of calling {@link > + * #getDeclaredAnnotations()} are assumed to be consistent with the > + * results of calling {@link #getDeclaredAnnotation(Class)}. > + * > > Thanks, > > -Joe From joe.darcy at oracle.com Wed Oct 30 16:01:32 2013 From: joe.darcy at oracle.com (Joe Darcy) Date: Wed, 30 Oct 2013 16:01:32 -0700 Subject: Proposal to make new-in-Java-SE-8 methods on AnnotatedElement default methods In-Reply-To: <527154DD.4090702@oracle.com> References: <5268C94A.8070208@oracle.com> <3677C436-B2C2-44D5-A2F7-EC46ED1AB301@oracle.com> <526968DB.2070806@oracle.com> <526A2D53.8080309@oracle.com> <526E9C9C.50904@oracle.com> <526F0DC8.7030809@oracle.com> <527154DD.4090702@oracle.com> Message-ID: <52718FCC.6090203@oracle.com> Hi Alex, Thanks for the close reading; I've changed this part of the @implSpec to: * @implSpec The default implementation first calls {@link * #getDeclaredAnnotationsByType(Class)} passing {@code * annotationClass} as the argument. If the returned array has * length greater than zero, the array is returned. If the returned * array is zero-length and this {@code AnnotatedElement} is a * class and the argument type is an inheritable annotation type, * and the superclass of this {@code AnnotatedElement} is non-null, * then the returned result is the result of calling {@link * #getAnnotationsByType(Class)} on the superclass with {@code * annotationClass} as the argument. Otherwise, a zero-length * array is returned. Cheers, -Joe On 10/30/2013 11:50 AM, Alex Buckley wrote: > spelling: AnnoatedElement > > Consider mentioning only the 'length' of an array, never its 'size' > (or at least use the same term within a single @implSpec). > > There's a {@code getAnnotationsByType} which is missing its (Class). > > Alex > [snip]