From alex.buckley at oracle.com Fri Aug 17 14:24:15 2012 From: alex.buckley at oracle.com (Alex Buckley) Date: Fri, 17 Aug 2012 14:24:15 -0700 Subject: Initial spec for Repeating Annotations and Method Parameter Reflection Message-ID: <502EB67F.5000909@oracle.com> Metadata fans, Oracle engineers have been working on Repeating Annotations and Method Parameter Reflection for a number of months. The design, specification, and implementation of Repeating Annotations is considerably advanced. We have a language specification and a detailed example-led description of how repeating annotations are compiled and how java.lang.reflect.AnnotatedElement can be improved. Method Parameter Reflection (I use this title because the feature is more than just parameter names) is much less advanced. We have a ClassFile specification to record parameter information, but many questions about the recording of parameter names are yet to be asked, let alone answered. I have consolidated all available material into a single, spec-licensed PDF: http://cr.openjdk.java.net/~abuckley/8misc.pdf Please send substantive technical comments about the material to this list. In the next few weeks, the implementation of Repeating Annotations should appear in the jdk8/tl forest, and we will start thinking about core reflection and language model (JSR 269) APIs for method parameters. If you are wondering whether Repeating Annotations interact with Type Annotations, you are right. An annotation on a type use should be repeatable just like an annotation on a declaration. The JSR 308 team is aware of this and will raise it with the JSR 308 Expert Group soon, followed by R.I. work in the Type Annotations Project. Alex From forax at univ-mlv.fr Tue Aug 21 06:57:06 2012 From: forax at univ-mlv.fr (=?UTF-8?B?UsOpbWkgRm9yYXg=?=) Date: Tue, 21 Aug 2012 15:57:06 +0200 Subject: Initial spec for Repeating Annotations and Method Parameter Reflection In-Reply-To: <502EB67F.5000909@oracle.com> References: <502EB67F.5000909@oracle.com> Message-ID: <503393B2.60004@univ-mlv.fr> On 08/17/2012 11:24 PM, Alex Buckley wrote: > Metadata fans, > > Oracle engineers have been working on Repeating Annotations and Method > Parameter Reflection for a number of months. > > The design, specification, and implementation of Repeating Annotations > is considerably advanced. We have a language specification and a > detailed example-led description of how repeating annotations are > compiled and how java.lang.reflect.AnnotatedElement can be improved. > > Method Parameter Reflection (I use this title because the feature is > more than just parameter names) is much less advanced. We have a > ClassFile specification to record parameter information, but many > questions about the recording of parameter names are yet to be asked, > let alone answered. > > I have consolidated all available material into a single, > spec-licensed PDF: > > http://cr.openjdk.java.net/~abuckley/8misc.pdf > > Please send substantive technical comments about the material to this > list. > > In the next few weeks, the implementation of Repeating Annotations > should appear in the jdk8/tl forest, and we will start thinking about > core reflection and language model (JSR 269) APIs for method parameters. > > If you are wondering whether Repeating Annotations interact with Type > Annotations, you are right. An annotation on a type use should be > repeatable just like an annotation on a declaration. The JSR 308 team > is aware of this and will raise it with the JSR 308 Expert Group soon, > followed by R.I. work in the Type Annotations Project. > > Alex Hi Alex, Hi all, I've just read the chapter 1, there is a small bug in the draft, section 9.6.3.8 (page 6 of the draft), ContainedBy is spelled ContainerAnnotation in the java code provided. In section Reflection, you forget to talk about the behavoir of isAnnotationPresent(), even if there is no big deal. Now, I don't see why @ContainerFor is needed, given that the compiler and the reflection runtime can use already existing information (the return type of value()) to reconstruct the information given by @ContainerFor. cheers, R?mi From alex.buckley at oracle.com Tue Aug 21 09:57:25 2012 From: alex.buckley at oracle.com (Alex Buckley) Date: Tue, 21 Aug 2012 09:57:25 -0700 Subject: Initial spec for Repeating Annotations and Method Parameter Reflection In-Reply-To: <503393B2.60004@univ-mlv.fr> References: <502EB67F.5000909@oracle.com> <503393B2.60004@univ-mlv.fr> Message-ID: <5033BDF5.4020800@oracle.com> Hi Remi, On 8/21/2012 6:57 AM, R?mi Forax wrote: > I've just read the chapter 1, there is a small bug in the draft, > section 9.6.3.8 (page 6 of the draft), ContainedBy is spelled > ContainerAnnotation in the java code provided. The code reflects an earlier internal draft and will be updated. > In section Reflection, you forget to talk about the behavoir of > isAnnotationPresent(), even if there is no big deal. Didn't forget. Small details like this will be tidied up as the feature progresses. > Now, I don't see why @ContainerFor is needed, given that the > compiler and the reflection runtime can use already existing > information (the return type of value()) to reconstruct the > information given by @ContainerFor. Initially we didn't have @ContainerFor, and thought it would be possible to "infer" that an annotation T is a "container" by checking that its value() element's return type T' is indeed an annotation type which expects to be contained by T. A small matter of programming, as some might say. However, for compatibility reasons, this turned out to be insufficient. Here's the reasoning: A marker annotation is needed because lines (1) and (2) below compile to the same ClassFile structure, yet the reflective API which operates on that structure needs to determine whether the repetition was implicit (1) or explicit (2) in order to give results that satisfy legacy consumers. (1) @Foo(1) @Foo(2) class A {} (2) @FooContainer({@Foo(1), @Foo(2)}) class A {} - If the source was (1), then A.class.get[Declared]Annotation(Foo.class) should "look through" the synthesized container and return @Foo(1). In particular, if the source was initially annotated with just @Foo(1), then adding @Foo(2) should not change the result from @Foo(1) to null (because the @Foo's were wrapped in a @FooContainer). The act of repeating an annotation is source-compatible, and a source-compatible change in code should not imply a behavior-incompatible change for reflective code. - If the source was (2), then A.class.get[Declared]Annotation(Foo.class) should _not_ look through @FooContainer (since it was written by hand in legacy code) and should return null (since there are logically no @Foo's on class A in (2)). You can see that it's not always desirable to "look through" an annotation which "appears" to be a container based on its value() element. The explicit @ContainerFor seems like a useful and reasonable piece of documentation. Alex From forax at univ-mlv.fr Tue Aug 21 11:53:34 2012 From: forax at univ-mlv.fr (=?UTF-8?B?UsOpbWkgRm9yYXg=?=) Date: Tue, 21 Aug 2012 20:53:34 +0200 Subject: Initial spec for Repeating Annotations and Method Parameter Reflection In-Reply-To: <5033BDF5.4020800@oracle.com> References: <502EB67F.5000909@oracle.com> <503393B2.60004@univ-mlv.fr> <5033BDF5.4020800@oracle.com> Message-ID: <5033D92E.6060708@univ-mlv.fr> On 08/21/2012 06:57 PM, Alex Buckley wrote: > Hi Remi, > > On 8/21/2012 6:57 AM, R?mi Forax wrote: >> I've just read the chapter 1, there is a small bug in the draft, >> section 9.6.3.8 (page 6 of the draft), ContainedBy is spelled >> ContainerAnnotation in the java code provided. > > The code reflects an earlier internal draft and will be updated. > >> In section Reflection, you forget to talk about the behavoir of >> isAnnotationPresent(), even if there is no big deal. > > Didn't forget. Small details like this will be tidied up as the feature > progresses. i know, i know :) > >> Now, I don't see why @ContainerFor is needed, given that the >> compiler and the reflection runtime can use already existing >> information (the return type of value()) to reconstruct the >> information given by @ContainerFor. > > Initially we didn't have @ContainerFor, and thought it would be possible > to "infer" that an annotation T is a "container" by checking that its > value() element's return type T' is indeed an annotation type which > expects to be contained by T. A small matter of programming, as some > might say. However, for compatibility reasons, this turned out to be > insufficient. Here's the reasoning: > > A marker annotation is needed because lines (1) and (2) below compile to > the same ClassFile structure, yet the reflective API which operates on > that structure needs to determine whether the repetition was implicit > (1) or explicit (2) in order to give results that satisfy legacy > consumers. > > (1) @Foo(1) @Foo(2) class A {} > (2) @FooContainer({@Foo(1), @Foo(2)}) class A {} > > - If the source was (1), then > A.class.get[Declared]Annotation(Foo.class) should "look through" the > synthesized container and return @Foo(1). In particular, if the source > was initially annotated with just @Foo(1), then adding @Foo(2) should > not change the result from @Foo(1) to null (because the @Foo's were > wrapped in a @FooContainer). The act of repeating an annotation is > source-compatible, and a source-compatible change in code should not > imply a behavior-incompatible change for reflective code. > > - If the source was (2), then > A.class.get[Declared]Annotation(Foo.class) should _not_ look through > @FooContainer (since it was written by hand in legacy code) and should > return null (since there are logically no @Foo's on class A in (2)). > > You can see that it's not always desirable to "look through" an > annotation which "appears" to be a container based on its value() > element. The explicit @ContainerFor seems like a useful and reasonable > piece of documentation. I think the following assumption is broken, [with get[Declared]Annotation(Foo.class)] "In particular, if the source was initially annotated with just @Foo(1), then adding @Foo(2) should not change the result from @Foo(1) to null" It should be true with get[Declared]Annotations (with an 's' at the end) not with get[Declared]Annotation, it's not a good idea to choose between the two Foo, because annotations are like modifiers, @Foo(1) @Foo(2) should be equivalent to @Foo(2) @Foo(1). And here, you clearly break that rule. So know that adding a repeated annotation can only be a source compatible change if users use get[Declared]Annotations(), @ContainerFor is not needed anymore :) > > Alex R?mi From alex.buckley at oracle.com Tue Aug 21 12:55:44 2012 From: alex.buckley at oracle.com (Alex Buckley) Date: Tue, 21 Aug 2012 12:55:44 -0700 Subject: Initial spec for Repeating Annotations and Method Parameter Reflection In-Reply-To: <5033D92E.6060708@univ-mlv.fr> References: <502EB67F.5000909@oracle.com> <503393B2.60004@univ-mlv.fr> <5033BDF5.4020800@oracle.com> <5033D92E.6060708@univ-mlv.fr> Message-ID: <5033E7C0.3090507@oracle.com> Our goal has generally been as much behavioral compatibility for AnnotatedElement methods as possible. I would rather continue to return "the first" @Foo annotation (which with any reasonable compiler is likely to be the same @Foo(1) as before) than return null and imply there is no @Foo annotation (especially since it's easily disproved by calling get[Declared]Annotations().) Alex On Tuesday, August 21, 2012 11:53:34 AM, R?mi Forax wrote: > I think the following assumption is broken, > [with get[Declared]Annotation(Foo.class)] > "In particular, if the source was initially annotated with just > @Foo(1), then adding @Foo(2) should not change the result from @Foo(1) > to null" > > It should be true with get[Declared]Annotations (with an 's' at the > end) not with get[Declared]Annotation, > it's not a good idea to choose between the two Foo, because > annotations are like modifiers, > @Foo(1) @Foo(2) should be equivalent to @Foo(2) @Foo(1). And here, you > clearly break that rule. > > So know that adding a repeated annotation can only be a source > compatible change if users use get[Declared]Annotations(), > @ContainerFor is not needed anymore :) > > R?mi From joel.franck at oracle.com Tue Aug 21 12:59:24 2012 From: joel.franck at oracle.com (=?iso-8859-1?Q?Joel_Borggr=E9n-Franck?=) Date: Tue, 21 Aug 2012 21:59:24 +0200 Subject: Initial spec for Repeating Annotations and Method Parameter Reflection In-Reply-To: <5033D92E.6060708@univ-mlv.fr> References: <502EB67F.5000909@oracle.com> <503393B2.60004@univ-mlv.fr> <5033BDF5.4020800@oracle.com> <5033D92E.6060708@univ-mlv.fr> Message-ID: <01CE4257-9AD1-4E97-9476-46D36E824223@oracle.com> Hi Remi, Thanks for your feedback! Inline, On Aug 21, 2012, at 8:53 PM, R?mi Forax wrote: > On 08/21/2012 06:57 PM, Alex Buckley wrote: >> >> Initially we didn't have @ContainerFor, and thought it would be possible >> to "infer" that an annotation T is a "container" by checking that its >> value() element's return type T' is indeed an annotation type which >> expects to be contained by T. A small matter of programming, as some >> might say. However, for compatibility reasons, this turned out to be >> insufficient. Here's the reasoning: >> >> A marker annotation is needed because lines (1) and (2) below compile to >> the same ClassFile structure, yet the reflective API which operates on >> that structure needs to determine whether the repetition was implicit >> (1) or explicit (2) in order to give results that satisfy legacy >> consumers. >> >> (1) @Foo(1) @Foo(2) class A {} >> (2) @FooContainer({@Foo(1), @Foo(2)}) class A {} >> >> - If the source was (1), then >> A.class.get[Declared]Annotation(Foo.class) should "look through" the >> synthesized container and return @Foo(1). In particular, if the source >> was initially annotated with just @Foo(1), then adding @Foo(2) should >> not change the result from @Foo(1) to null (because the @Foo's were >> wrapped in a @FooContainer). The act of repeating an annotation is >> source-compatible, and a source-compatible change in code should not >> imply a behavior-incompatible change for reflective code. >> >> - If the source was (2), then >> A.class.get[Declared]Annotation(Foo.class) should _not_ look through >> @FooContainer (since it was written by hand in legacy code) and should >> return null (since there are logically no @Foo's on class A in (2)). >> >> You can see that it's not always desirable to "look through" an annotation which "appears" to be a container based on its value() element. The explicit @ContainerFor seems like a useful and reasonable piece of documentation. > > I think the following assumption is broken, > [with get[Declared]Annotation(Foo.class)] > "In particular, if the source was initially annotated with just @Foo(1), then adding @Foo(2) should not change the result from @Foo(1) to null" > > It should be true with get[Declared]Annotations (with an 's' at the end) not with get[Declared]Annotation, > it's not a good idea to choose between the two Foo, because annotations are like modifiers, > @Foo(1) @Foo(2) should be equivalent to @Foo(2) @Foo(1). And here, you clearly break that rule. > I disagree with you on this point. While implementing this I did a lot of hallway testing, and all the people I asked think that in the example above, get[Declared]Annotation(Foo.class) => null is a (much) bigger bad than choosing, say, the leftmost in a left-to-right source order. Foo-annotations are present in the source, and while reflection ins't a 1-1 mapping to source programmers tend to want that. We already live with the problem that runtime retention isn't the default, we shouldn't make the source-to-reflection gap bigger. Also note that on the byte code level, the proposed spec writeup says that @Foo(1) @Foo(2) isn't equivalent to @Foo(2) @Foo(1). cheers /Joel From forax at univ-mlv.fr Tue Aug 21 13:45:07 2012 From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=) Date: Tue, 21 Aug 2012 22:45:07 +0200 Subject: Initial spec for Repeating Annotations and Method Parameter Reflection In-Reply-To: <01CE4257-9AD1-4E97-9476-46D36E824223@oracle.com> References: <502EB67F.5000909@oracle.com> <503393B2.60004@univ-mlv.fr> <5033BDF5.4020800@oracle.com> <5033D92E.6060708@univ-mlv.fr> <01CE4257-9AD1-4E97-9476-46D36E824223@oracle.com> Message-ID: <5033F353.6040407@univ-mlv.fr> On 08/21/2012 09:59 PM, Joel Borggr?n-Franck wrote: > Hi Remi, > > Thanks for your feedback! > > Inline, > > On Aug 21, 2012, at 8:53 PM, R?mi Forax wrote: > >> On 08/21/2012 06:57 PM, Alex Buckley wrote: >>> Initially we didn't have @ContainerFor, and thought it would be possible >>> to "infer" that an annotation T is a "container" by checking that its >>> value() element's return type T' is indeed an annotation type which >>> expects to be contained by T. A small matter of programming, as some >>> might say. However, for compatibility reasons, this turned out to be >>> insufficient. Here's the reasoning: >>> >>> A marker annotation is needed because lines (1) and (2) below compile to >>> the same ClassFile structure, yet the reflective API which operates on >>> that structure needs to determine whether the repetition was implicit >>> (1) or explicit (2) in order to give results that satisfy legacy >>> consumers. >>> >>> (1) @Foo(1) @Foo(2) class A {} >>> (2) @FooContainer({@Foo(1), @Foo(2)}) class A {} >>> >>> - If the source was (1), then >>> A.class.get[Declared]Annotation(Foo.class) should "look through" the >>> synthesized container and return @Foo(1). In particular, if the source >>> was initially annotated with just @Foo(1), then adding @Foo(2) should >>> not change the result from @Foo(1) to null (because the @Foo's were >>> wrapped in a @FooContainer). The act of repeating an annotation is >>> source-compatible, and a source-compatible change in code should not >>> imply a behavior-incompatible change for reflective code. >>> >>> - If the source was (2), then >>> A.class.get[Declared]Annotation(Foo.class) should _not_ look through >>> @FooContainer (since it was written by hand in legacy code) and should >>> return null (since there are logically no @Foo's on class A in (2)). >>> >>> You can see that it's not always desirable to "look through" an annotation which "appears" to be a container based on its value() element. The explicit @ContainerFor seems like a useful and reasonable piece of documentation. >> I think the following assumption is broken, >> [with get[Declared]Annotation(Foo.class)] >> "In particular, if the source was initially annotated with just @Foo(1), then adding @Foo(2) should not change the result from @Foo(1) to null" >> >> It should be true with get[Declared]Annotations (with an 's' at the end) not with get[Declared]Annotation, >> it's not a good idea to choose between the two Foo, because annotations are like modifiers, >> @Foo(1) @Foo(2) should be equivalent to @Foo(2) @Foo(1). And here, you clearly break that rule. >> > I disagree with you on this point. While implementing this I did a lot of hallway testing, and all the people I asked think that in the example above, > > get[Declared]Annotation(Foo.class) => null > > is a (much) bigger bad than choosing, say, the leftmost in a left-to-right source order. We all know that it depends how you ask the question, i.e. I suppose you don't paint the whole picture, see below. > Foo-annotations are present in the source, and while reflection ins't a 1-1 mapping to source programmers tend to want that. You can't say, the user has to be aware that he has to declare a container annotation, this is not a hidden detail, and at the same time say that we should provide a 1-1 mapping. Also Java has a long tradition of ignoring the order of the declaration element, especially modifiers. Just ask the the people if they think that @Foo(1) @Foo(2) class A {} should be behaviorally different from @Foo(2) @Foo(1) class A {} There is no free lunch here, and I do think that the proposed design is not the right trade off, users of the reflection API, users that create annotations and container annotations will be fully aware that in the bytecode an annotation container will be used, so I think that trying to hide a detail they will have to know just plain wrong. so get[Declared]Annotation can return null if the javadoc explains that users should use get[Declared]Annotation instead. > We already live with the problem that runtime retention isn't the default, we shouldn't make the source-to-reflection gap bigger. You also see the hidden parameters of the enum constructor, you can't access to enclosing private variable and so on. > > Also note that on the byte code level, the proposed spec writeup says that @Foo(1) @Foo(2) isn't equivalent to @Foo(2) @Foo(1). > > cheers > /Joel cheers, R?mi From joel.franck at oracle.com Tue Aug 21 22:39:02 2012 From: joel.franck at oracle.com (=?iso-8859-1?Q?Joel_Borggr=E9n-Franck?=) Date: Wed, 22 Aug 2012 07:39:02 +0200 Subject: Initial spec for Repeating Annotations and Method Parameter Reflection In-Reply-To: <5033F353.6040407@univ-mlv.fr> References: <502EB67F.5000909@oracle.com> <503393B2.60004@univ-mlv.fr> <5033BDF5.4020800@oracle.com> <5033D92E.6060708@univ-mlv.fr> <01CE4257-9AD1-4E97-9476-46D36E824223@oracle.com> <5033F353.6040407@univ-mlv.fr> Message-ID: <157BDCFF-DCA3-430D-A9A8-CDE1CFAF773D@oracle.com> On 21 aug 2012, at 22:45, R?mi Forax wrote: > On 08/21/2012 09:59 PM, Joel Borggr?n-Franck wrote: > >> We already live with the problem that runtime retention isn't the default, we shouldn't make the source-to-reflection gap bigger. > > You also see the hidden parameters of the enum constructor, you can't access to enclosing private variable and so on. Yes, many wrongs doesn't make a right. cheers /Joel From forax at univ-mlv.fr Wed Aug 22 14:11:50 2012 From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=) Date: Wed, 22 Aug 2012 23:11:50 +0200 Subject: Initial spec for Repeating Annotations and Method Parameter Reflection In-Reply-To: <157BDCFF-DCA3-430D-A9A8-CDE1CFAF773D@oracle.com> References: <502EB67F.5000909@oracle.com> <503393B2.60004@univ-mlv.fr> <5033BDF5.4020800@oracle.com> <5033D92E.6060708@univ-mlv.fr> <01CE4257-9AD1-4E97-9476-46D36E824223@oracle.com> <5033F353.6040407@univ-mlv.fr> <157BDCFF-DCA3-430D-A9A8-CDE1CFAF773D@oracle.com> Message-ID: <50354B16.60207@univ-mlv.fr> On 08/22/2012 07:39 AM, Joel Borggr?n-Franck wrote: > On 21 aug 2012, at 22:45, R?mi Forax wrote: > >> On 08/21/2012 09:59 PM, Joel Borggr?n-Franck wrote: >> >>> We already live with the problem that runtime retention isn't the default, we shouldn't make the source-to-reflection gap bigger. >> You also see the hidden parameters of the enum constructor, you can't access to enclosing private variable and so on. > Yes, many wrongs doesn't make a right. or it's just because reflection reflects bytecode view and not Java view. > > cheers > /Joel regards, R?mi From joe.darcy at oracle.com Tue Aug 28 18:15:06 2012 From: joe.darcy at oracle.com (Joe Darcy) Date: Tue, 28 Aug 2012 18:15:06 -0700 Subject: Suggested clarification on Target subletting logic and on repeatability Message-ID: <503D6D1A.20901@oracle.com> Hi Alex, Two suggested clarifications to the 2012-08-17 version of the specification [1]: * Repeatability per target. It would be helpful if section 9.7 included at least an informative note that an annotation type can be viewed as being repeatable on a per-target basis depending on the declaration of the target list of the container annotation. There is a similar note on this point in 9.6 but I think it bears mention in 9.7 too. * For the purposes of checking Target subsetting in 9.6, the set {ElementType.ANNOTATION_TYPE} is a subset of {ElementType.TYPE} since annotation types are a subset of general types. Cheers, -Joe [1] http://cr.openjdk.java.net/~abuckley/8misc.pdf From bill.shannon at oracle.com Wed Aug 29 12:05:34 2012 From: bill.shannon at oracle.com (Bill Shannon) Date: Wed, 29 Aug 2012 12:05:34 -0700 Subject: Initial spec for Repeating Annotations and Method Parameter Reflection Message-ID: <503E67FE.7010807@oracle.com> Just to provide a little background for people here... This is something we've been asking for for some time to support our use of annotations in Java EE. We worked with Alex to ensure that this proposal will meet our needs. We believe it does, and we plan to retrofit our existing annotations to take advantage of this new feature when it's available. Thanks to Alex for putting this together and working through all the details to make it a formal spec! Bill Shannon Java EE Spec Lead From alex.buckley at oracle.com Wed Aug 29 14:30:48 2012 From: alex.buckley at oracle.com (Alex Buckley) Date: Wed, 29 Aug 2012 14:30:48 -0700 Subject: Suggested clarification on Target subletting logic and on repeatability In-Reply-To: <503D6D1A.20901@oracle.com> References: <503D6D1A.20901@oracle.com> Message-ID: <503E8A08.70905@oracle.com> Thanks Joe, I have updated 9.6 and 9.7 as you suggest. In general, when I update the spec (8misc.pdf), I will rename the previous version according to its date (8misc-20120817.pdf). All will be visible at http://cr.openjdk.java.net/~abuckley/. Alex On 8/28/2012 6:15 PM, Joe Darcy wrote: > Hi Alex, > > Two suggested clarifications to the 2012-08-17 version of the > specification [1]: > > * Repeatability per target. It would be helpful if section 9.7 included > at least an informative note that an annotation type can be viewed as > being repeatable on a per-target basis depending on the declaration of > the target list of the container annotation. There is a similar note on > this point in 9.6 but I think it bears mention in 9.7 too. > > * For the purposes of checking Target subsetting in 9.6, the set > {ElementType.ANNOTATION_TYPE} is a subset of {ElementType.TYPE} since > annotation types are a subset of general types. > > Cheers, > > -Joe > > [1] http://cr.openjdk.java.net/~abuckley/8misc.pdf From joe.darcy at oracle.com Thu Aug 30 17:09:16 2012 From: joe.darcy at oracle.com (Joseph Darcy) Date: Thu, 30 Aug 2012 17:09:16 -0700 Subject: Suggestion for additional discussion of annotation evolution vis a vis repeatability in JLS 13.5.7 Message-ID: <504000AC.7010202@oracle.com> Hello, Chapter 13 of the JLS discusses binary compatibility and 13.5.7 discussions some considerations specific to annotation types. I think it would be appropriate and helpful for this discussion to include repeatability of annotation types, binary compatibility is not changed, source and behavioral might be, etc. Cheers, -Joe