From alex.buckley at oracle.com Fri Feb 1 11:39:25 2013 From: alex.buckley at oracle.com (Alex Buckley) Date: Fri, 01 Feb 2013 11:39:25 -0800 Subject: Spec updates for getAnnotationsByType and implicit declarations In-Reply-To: <510B2875.4060001@oracle.com> References: <510B2875.4060001@oracle.com> Message-ID: <510C19ED.8040703@oracle.com> On 1/31/2013 6:29 PM, Alex Buckley wrote: > (It is generally better for the JVMS to provide a space which meets > the requirements of what a compiler would need to represent a > language construct, than the JLS saving exactly how to map a language > construct into a class file. Typo, meant: ... would need to represent a language construct, rather than the JLS saying exactly how ... Also I should have mentioned that, following discussion with Joe, I renamed isSynthesized() in j.l.r.Parameter to isImplicit(), and bound the specifications of isImplicit() and isSynthetic() to the same "explicitly/implicitly declared" concept as in the ClassFile attribute. Alex From pbenedict at apache.org Fri Feb 1 11:47:07 2013 From: pbenedict at apache.org (Paul Benedict) Date: Fri, 1 Feb 2013 13:47:07 -0600 Subject: Parameter reflection: duplicate parameter names Message-ID: I know parameter names are irrelevant to the JVM, but the spec doesn't explain how this poor situation will be handled. Should it at least be mention it's expected for all names to be unique? Or leave the behavior undefined? It might matter to the implementator -- especially if a HashMap<> could be used internally to store the names. Paul From alex.buckley at oracle.com Fri Feb 1 12:03:40 2013 From: alex.buckley at oracle.com (Alex Buckley) Date: Fri, 01 Feb 2013 12:03:40 -0800 Subject: Parameter reflection: duplicate parameter names In-Reply-To: References: Message-ID: <510C1F9C.4000700@oracle.com> Core reflection has always exposed what ever is in the class file, which may always have been generated by a non-Java compiler. Especially for a new reflective construct which we want non-Java compilers to use, it is futile to try to constrain core reflection to hide content which is not Java-compliant, or throw exceptions for it. Alex On 2/1/2013 11:47 AM, Paul Benedict wrote: > I know parameter names are irrelevant to the JVM, but the spec doesn't > explain how this poor situation will be handled. Should it at least be > mention it's expected for all names to be unique? Or leave the behavior > undefined? It might matter to the implementator -- especially if a > HashMap<> could be used internally to store the names. > > Paul > From pbenedict at apache.org Fri Feb 1 12:13:35 2013 From: pbenedict at apache.org (Paul Benedict) Date: Fri, 1 Feb 2013 14:13:35 -0600 Subject: Parameter reflection: duplicate parameter names In-Reply-To: <510C1F9C.4000700@oracle.com> References: <510C1F9C.4000700@oracle.com> Message-ID: Agreed. So shouldn't there be a mention that implementers should not assume parameter names are unique? For example, what you said could easily be attached to the spec to make that clear. Paul On Fri, Feb 1, 2013 at 2:03 PM, Alex Buckley wrote: > Core reflection has always exposed what ever is in the class file, which > may always have been generated by a non-Java compiler. Especially for a new > reflective construct which we want non-Java compilers to use, it is futile > to try to constrain core reflection to hide content which is not > Java-compliant, or throw exceptions for it. > > Alex > > > On 2/1/2013 11:47 AM, Paul Benedict wrote: > >> I know parameter names are irrelevant to the JVM, but the spec doesn't >> explain how this poor situation will be handled. Should it at least be >> mention it's expected for all names to be unique? Or leave the behavior >> undefined? It might matter to the implementator -- especially if a >> HashMap<> could be used internally to store the names. >> >> Paul >> >> From alex.buckley at oracle.com Mon Feb 4 11:58:21 2013 From: alex.buckley at oracle.com (Alex Buckley) Date: Mon, 04 Feb 2013 11:58:21 -0800 Subject: Spec updates for getAnnotationsByType and implicit declarations In-Reply-To: <510B2875.4060001@oracle.com> References: <510B2875.4060001@oracle.com> Message-ID: <511012DD.9090704@oracle.com> I just updated the PDF with minor corrections related to the changes below. Notably, container annotations are now "implicitly declared", but only implicitly declared formal parameters (not other constructs) must be marked by a compiler. Alex On 1/31/2013 6:29 PM, Alex Buckley wrote: > For repeating annotations, I adopted > get[Declared]AnnotationsByType(Class) in the reflection APIs, and > clarified the definitions of "directly present" and "present". > > For parameter reflection, I did the groundwork for "implicitly declared" > constructs in the JLS, and clarified that a compiler is to mark > constructs based on whether they are explicitly or implicitly declared. > A compiler which emits class files can conform by utilizing the > ACC_SYNTHETIC and ACC_MANDATED flags described in JVMS 4.7.22. These > flags defer to a language specification for their full meaning. (It is > generally better for the JVMS to provide a space which meets the > requirements of what a compiler would need to represent a language > construct, than the JLS saving exactly how to map a language construct > into a class file. Example: the Signature attribute, JVMS 4.7.9.) > > The spec is at http://cr.openjdk.java.net/~abuckley/8misc.pdf as usual. > > Alex > > P.S. There was minor discussion on the GPL'd compiler-dev list about > naming the ACC_MANDATED flag, starting at > http://mail.openjdk.java.net/pipermail/compiler-dev/2013-January/005450.html > From alex.buckley at oracle.com Mon Feb 11 11:45:12 2013 From: alex.buckley at oracle.com (Alex Buckley) Date: Mon, 11 Feb 2013 11:45:12 -0800 Subject: Parameter reflection: duplicate parameter names In-Reply-To: References: <510C1F9C.4000700@oracle.com> Message-ID: <51194A48.8030407@oracle.com> I have suggested to Eric McCorkle that the javadoc for Executable.getParameters should set expectations for clients by saying: "The parameters of the underlying executable do not necessarily have unique names, or names that are legal identifiers in the Java programming language (JLS 3.8)." Alex On 2/1/2013 12:13 PM, Paul Benedict wrote: > Agreed. So shouldn't there be a mention that implementers should not > assume parameter names are unique? For example, what you said could > easily be attached to the spec to make that clear. > > Paul > > On Fri, Feb 1, 2013 at 2:03 PM, Alex Buckley > wrote: > > Core reflection has always exposed what ever is in the class file, > which may always have been generated by a non-Java compiler. > Especially for a new reflective construct which we want non-Java > compilers to use, it is futile to try to constrain core reflection > to hide content which is not Java-compliant, or throw exceptions for it. > > Alex > > > On 2/1/2013 11:47 AM, Paul Benedict wrote: > > I know parameter names are irrelevant to the JVM, but the spec > doesn't > explain how this poor situation will be handled. Should it at > least be > mention it's expected for all names to be unique? Or leave the > behavior > undefined? It might matter to the implementator -- especially if a > HashMap<> could be used internally to store the names. > > Paul From eric.mccorkle at oracle.com Mon Feb 11 12:11:29 2013 From: eric.mccorkle at oracle.com (Eric McCorkle) Date: Mon, 11 Feb 2013 15:11:29 -0500 Subject: Parameter reflection: duplicate parameter names In-Reply-To: <51194A48.8030407@oracle.com> References: <510C1F9C.4000700@oracle.com> <51194A48.8030407@oracle.com> Message-ID: <51195071.1080008@oracle.com> That comment change should be going in with 8007405 On 02/11/13 14:45, Alex Buckley wrote: > I have suggested to Eric McCorkle that the javadoc for > Executable.getParameters should set expectations for clients by saying: > > "The parameters of the underlying executable do not necessarily have > unique names, or names that are legal identifiers in the Java > programming language (JLS 3.8)." > > Alex > > On 2/1/2013 12:13 PM, Paul Benedict wrote: >> Agreed. So shouldn't there be a mention that implementers should not >> assume parameter names are unique? For example, what you said could >> easily be attached to the spec to make that clear. >> >> Paul >> >> On Fri, Feb 1, 2013 at 2:03 PM, Alex Buckley > > wrote: >> >> Core reflection has always exposed what ever is in the class file, >> which may always have been generated by a non-Java compiler. >> Especially for a new reflective construct which we want non-Java >> compilers to use, it is futile to try to constrain core reflection >> to hide content which is not Java-compliant, or throw exceptions >> for it. >> >> Alex >> >> >> On 2/1/2013 11:47 AM, Paul Benedict wrote: >> >> I know parameter names are irrelevant to the JVM, but the spec >> doesn't >> explain how this poor situation will be handled. Should it at >> least be >> mention it's expected for all names to be unique? Or leave the >> behavior >> undefined? It might matter to the implementator -- especially >> if a >> HashMap<> could be used internally to store the names. >> >> Paul From joe.darcy at oracle.com Thu Feb 14 16:15:34 2013 From: joe.darcy at oracle.com (Joseph Darcy) Date: Thu, 14 Feb 2013 16:15:34 -0800 Subject: Proposal to remove java.lang.annotation.InvalidContainerAnnotationError Message-ID: <511D7E26.4050605@oracle.com> Hello, From the recent changes in the repeating annotation feature, it seems that java.lang.annotation.InvalidContainerAnnotationError does not pull its weight as a separate public type and that its superclass, AnnotationFormatError from Java SE 5, should just be used instead. Any objections to removing InvalidContainerAnnotationError? Please respond by February 19. Thanks, -Joe From alex.buckley at oracle.com Thu Feb 14 16:20:14 2013 From: alex.buckley at oracle.com (Alex Buckley) Date: Thu, 14 Feb 2013 16:20:14 -0800 Subject: Proposal to remove java.lang.annotation.InvalidContainerAnnotationError In-Reply-To: <511D7E26.4050605@oracle.com> References: <511D7E26.4050605@oracle.com> Message-ID: <511D7F3E.8090205@oracle.com> No objection from me. The condition for throwing an AnnotationFormatError was deliberately broad in order to i) mirror a compile-time rule and ii) not over-emphasize a fairly rare situation. Alex On 2/14/2013 4:15 PM, Joseph Darcy wrote: > Hello, > > From the recent changes in the repeating annotation feature, it seems that > > java.lang.annotation.InvalidContainerAnnotationError > > does not pull its weight as a separate public type and that its > superclass, AnnotationFormatError from Java SE 5, should just be used > instead. > > Any objections to removing InvalidContainerAnnotationError? Please > respond by February 19. > > Thanks, > > -Joe From joe.darcy at oracle.com Thu Feb 21 12:23:15 2013 From: joe.darcy at oracle.com (Joe Darcy) Date: Thu, 21 Feb 2013 12:23:15 -0800 Subject: some more fiddling In-Reply-To: <5101B255.4060904@oracle.com> References: <5101A4A2.7030801@oracle.com> <5101B255.4060904@oracle.com> Message-ID: <51268233.9060408@oracle.com> Hello Mike, Following up on this thread... On 1/24/2013 2:14 PM, Joe Darcy wrote: > Hi Mike, > > On 1/24/2013 1:16 PM, michael keith wrote: >> So I did some playing around with b72 in a couple of ways. >> >> First, I went and modified all of the current JPA container >> annotations to be JDK 8 repeatable (using @ContainerFor and >> @ContainedBy, since @Repeatable did not seem to be included) and >> compiled it using b72. > > The transition to the simplified @Repeatable model is happening in > stages. Build 73 of JDK 8 has the Repeatable type, but no compiler > and reflection support. The compiler support is in the team > repository now (bug 8006119) and should appear in a near-future > promoted build. However, the core reflection changes to revert back > to the JDK 7 and earlier behavior are not implemented yet. > >> Then I took the JPA RI (EclipseLink) code and its existing JPA tests >> and built them using JDK 1.7_11. I then ran the tests using b72 and >> found that all of the tests passed, so basically existing code and >> test cases compiled using a previous JDK will continue to work (at >> least in the test cases that I ran). So the first "do no harm" test >> seems to have passed :-) > > Good to hear :-) > >> >> The next thing I did was up the ante and move on to creating tests >> using new features (e.g. repeating annotations) to see how compatible >> the code would be. In other words, I wanted to make sure the same >> processing code could handle repeating annotations using the old API. >> It turned out not to work, though, so either the compatibility layer >> that we discussed before Christmas isn't done yet, or the current >> support just doesn't work as expected. For example, invoking >> getAnnotation(Foo.class) on both >> >> @Foo(1) @Foo(2) >> class A {} >> >> and >> >> @FooContainer({@Foo(1), @Foo(2)}) >> class A {} >> >> both returned @Foo(1). In both of these cases it should have returned >> null. >> >> This, combined with the fact that the Repeatable annotation was not >> shipped in b72 leads me to believe that the compatibility support is >> still forthcoming. Do you folks have any estimates for when it will >> be ready to try out? >> > > The core reflection changes should be in a promoted build within a few > weeks. > > The core reflection changes in question to revert the behavior of the existing AnnotatedElement methods to be oblivious to repeatability are in the current build of JDK 8, b77. Please re-run your experiments to see if the existing processing code works running under JDK 8 with annotation types that have been upgraded to be @Repeatable. (There is an in-progress rename of some of the new methods, but that won't affect this experiment.) Thanks, -Joe From joe.darcy at oracle.com Fri Feb 22 19:41:54 2013 From: joe.darcy at oracle.com (Joe Darcy) Date: Fri, 22 Feb 2013 19:41:54 -0800 Subject: Proposal to remove java.lang.annotation.InvalidContainerAnnotationError In-Reply-To: <511D7F3E.8090205@oracle.com> References: <511D7E26.4050605@oracle.com> <511D7F3E.8090205@oracle.com> Message-ID: <51283A82.7080904@oracle.com> Upon hearing no objections, I will move forward on removing InvalidContainerAnnotationError from Java SE 8. Thanks, -Joe On 2/14/2013 4:20 PM, Alex Buckley wrote: > No objection from me. The condition for throwing an > AnnotationFormatError was deliberately broad in order to i) mirror a > compile-time rule and ii) not over-emphasize a fairly rare situation. > > Alex > > On 2/14/2013 4:15 PM, Joseph Darcy wrote: >> Hello, >> >> From the recent changes in the repeating annotation feature, it >> seems that >> >> java.lang.annotation.InvalidContainerAnnotationError >> >> does not pull its weight as a separate public type and that its >> superclass, AnnotationFormatError from Java SE 5, should just be used >> instead. >> >> Any objections to removing InvalidContainerAnnotationError? Please >> respond by February 19. >> >> Thanks, >> >> -Joe From pbenedict at apache.org Thu Feb 28 09:41:17 2013 From: pbenedict at apache.org (Paul Benedict) Date: Thu, 28 Feb 2013 11:41:17 -0600 Subject: Parameter::getName() Message-ID: The opening Javadoc sentences: "Returns the name of the parameter. The names of the parameters of a single executable must all the be distinct." It was my understanding that parameter names are not necessarily distinct: http://mail.openjdk.java.net/pipermail/enhanced-metadata-spec-discuss/2013-February/000148.html Paul From eric.mccorkle at oracle.com Thu Feb 28 09:50:57 2013 From: eric.mccorkle at oracle.com (Eric McCorkle) Date: Thu, 28 Feb 2013 12:50:57 -0500 Subject: Parameter::getName() In-Reply-To: References: Message-ID: <512F9901.8050807@oracle.com> The parameter reflection API reports exactly what is present in a class file. It is correct that there is no guarantee parameter names are unique for a given method (consider, for example, a class file generated for a non-java language that allows the same name for multiple parameters) On 02/28/13 12:41, Paul Benedict wrote: > The opening Javadoc sentences: "Returns the name of the parameter. The > names of the parameters of a single executable must all the be distinct." > > It was my understanding that parameter names are not necessarily distinct: > http://mail.openjdk.java.net/pipermail/enhanced-metadata-spec-discuss/2013-February/000148.html > > Paul > From pbenedict at apache.org Thu Feb 28 10:07:19 2013 From: pbenedict at apache.org (Paul Benedict) Date: Thu, 28 Feb 2013 12:07:19 -0600 Subject: Parameter::getName() In-Reply-To: <512F9901.8050807@oracle.com> References: <512F9901.8050807@oracle.com> Message-ID: Okay, so the javadoc needs updating. Removing the second line would be appropriate. On Thu, Feb 28, 2013 at 11:50 AM, Eric McCorkle wrote: > The parameter reflection API reports exactly what is present in a class > file. It is correct that there is no guarantee parameter names are > unique for a given method (consider, for example, a class file generated > for a non-java language that allows the same name for multiple parameters) > > On 02/28/13 12:41, Paul Benedict wrote: > > The opening Javadoc sentences: "Returns the name of the parameter. The > > names of the parameters of a single executable must all the be distinct." > > > > It was my understanding that parameter names are not necessarily > distinct: > > > http://mail.openjdk.java.net/pipermail/enhanced-metadata-spec-discuss/2013-February/000148.html > > > > Paul > > > From alex.buckley at oracle.com Thu Feb 28 10:57:48 2013 From: alex.buckley at oracle.com (Alex Buckley) Date: Thu, 28 Feb 2013 10:57:48 -0800 Subject: Parameter::getName() In-Reply-To: <512F9901.8050807@oracle.com> References: <512F9901.8050807@oracle.com> Message-ID: <512FA8AC.6030800@oracle.com> Eric, JDK-8007405 is marked as fixed in b78, but the corresponding changeset (f21a4b761424) still has Parameter#getName saying parameter names "must all the be distinct" (and some other spelling errors). Alex On 2/28/2013 9:50 AM, Eric McCorkle wrote: > The parameter reflection API reports exactly what is present in a class > file. It is correct that there is no guarantee parameter names are > unique for a given method (consider, for example, a class file generated > for a non-java language that allows the same name for multiple parameters) > > On 02/28/13 12:41, Paul Benedict wrote: >> The opening Javadoc sentences: "Returns the name of the parameter. The >> names of the parameters of a single executable must all the be distinct." >> >> It was my understanding that parameter names are not necessarily distinct: >> http://mail.openjdk.java.net/pipermail/enhanced-metadata-spec-discuss/2013-February/000148.html >> >> Paul >>