From alex.buckley at oracle.com Fri Nov 9 12:31:06 2012 From: alex.buckley at oracle.com (Alex Buckley) Date: Fri, 09 Nov 2012 12:31:06 -0800 Subject: Spec updates for method parameter reflection Message-ID: <509D680A.4070201@oracle.com> I have updated the spec to describe the core reflection API and language model API for method (and constructor) parameters. I also give a rationale for Oracle's new policy of _not_ storing parameter names in class files by default. For repeating annotations, there is a clarification of the rule about mixing annotations of repeatable and containing annotation types on the same declaration (see page 8), and minor corrections to the core reflection API examples and the language model API description. The spec is at http://cr.openjdk.java.net/~abuckley/8misc.pdf as usual. Alex From forax at univ-mlv.fr Sat Nov 10 04:40:53 2012 From: forax at univ-mlv.fr (Remi Forax) Date: Sat, 10 Nov 2012 13:40:53 +0100 Subject: Spec updates for method parameter reflection In-Reply-To: <509D680A.4070201@oracle.com> References: <509D680A.4070201@oracle.com> Message-ID: <509E4B55.60507@univ-mlv.fr> On 11/09/2012 09:31 PM, Alex Buckley wrote: > I have updated the spec to describe the core reflection API and > language model API for method (and constructor) parameters. > > I also give a rationale for Oracle's new policy of _not_ storing > parameter names in class files by default. > > For repeating annotations, there is a clarification of the rule about > mixing annotations of repeatable and containing annotation types on > the same declaration (see page 8), and minor corrections to the core > reflection API examples and the language model API description. > > The spec is at http://cr.openjdk.java.net/~abuckley/8misc.pdf as usual. > > Alex I've only read the parameter name part of the spec*. The way the method attribute "MethodParameters_atttribute" is defined is cleaner. I think the default policy (don't include parameter names) is not the good one. While I agree that enable reified parameter everywhere can severely impact class file size (the runtime part can be lazy), there is a third option between enable and disable, enable parameter names selectively. I propose the following default policy, parameter names are enabled by default only if the methods is annotated with an annotation with the retention CLASS or RUNTIME. The idea is that if the method is annotated, the parameter names should be visible by a class enhancer or the reflection API. cheers, R?mi * I suppose that I should mention that I still think that @ContainedBy is superfluous. From alex.buckley at oracle.com Mon Nov 12 11:10:50 2012 From: alex.buckley at oracle.com (Alex Buckley) Date: Mon, 12 Nov 2012 11:10:50 -0800 Subject: Spec updates for method parameter reflection In-Reply-To: <509E4B55.60507@univ-mlv.fr> References: <509D680A.4070201@oracle.com> <509E4B55.60507@univ-mlv.fr> Message-ID: <50A149BA.6030706@oracle.com> On 11/10/2012 4:40 AM, Remi Forax wrote: > I think the default policy (don't include parameter names) is not the > good one. While I agree that enable reified parameter everywhere can > severely impact class file size (the runtime part can be lazy), there > is a third option between enable and disable, enable parameter names > selectively. > > I propose the following default policy, parameter names are enabled > by default only if the methods is annotated with an annotation with > the retention CLASS or RUNTIME. > > The idea is that if the method is annotated, the parameter names > should be visible by a class enhancer or the reflection API. There are many ideas for an "opt in" mechanism: - Explicit: @ReifyParameters annotation on a class - Explicit: @ReifyParameters annotation on a method - Semi-explicit: @ReifyParameters meta-annotation on a class annotation - Semi-explicit: @ReifyParameters meta-annotation on a method annotation - Implicit: Presence of any RUNTIME-retention annotation on a class - Implicit: Presence of any RUNTIME-retention annotation on a method - Implicit: Presence of any CLASS/RUNTIME-retention annotation on a class - Implicit: Presence of any CLASS/RUNTIME-retention annotation on a method Opinions differ on which is best. It seems risky at this time to commit to one mechanism, since it would have to be supported forever even if consensus comes round to a different mechanism. For this reason, we will avoid defining a standard "opt in" mechanism for Java SE 8. Alex From leonid.arbouzov at oracle.com Mon Nov 12 14:35:30 2012 From: leonid.arbouzov at oracle.com (Leonid Arbouzov) Date: Mon, 12 Nov 2012 14:35:30 -0800 Subject: Spec updates for method parameter reflection In-Reply-To: <50A149BA.6030706@oracle.com> References: <509D680A.4070201@oracle.com> <509E4B55.60507@univ-mlv.fr> <50A149BA.6030706@oracle.com> Message-ID: <50A179B2.1050008@oracle.com> What would be conformance requirements for this feature? For example, would a Java compiler be in conformance with the spec in the following cases: - the compiler generate parameter names by default for all classes (no way to suppress it), - the compiler ignores the option controlling parameter names generation (no way to turn it on), - the compiler generate parameter names selectively (let's say for public methods only), - the compiler supports private (implementation-specific) annotations controlling parameter names generation, - the compiler somehow modifies parameter names (let's say prefixing with... "param_"). BTW, compared with an option approach @ReifyParameters annotation could allow more accurately specify and check Java compiler behavior ...if it is important in that case. Thanks, -leonid On 11/12/2012 11:10 AM, Alex Buckley wrote: > On 11/10/2012 4:40 AM, Remi Forax wrote: >> I think the default policy (don't include parameter names) is not the >> good one. While I agree that enable reified parameter everywhere can >> severely impact class file size (the runtime part can be lazy), there >> is a third option between enable and disable, enable parameter names >> selectively. >> >> I propose the following default policy, parameter names are enabled >> by default only if the methods is annotated with an annotation with >> the retention CLASS or RUNTIME. >> >> The idea is that if the method is annotated, the parameter names >> should be visible by a class enhancer or the reflection API. > > There are many ideas for an "opt in" mechanism: > > - Explicit: @ReifyParameters annotation on a class > - Explicit: @ReifyParameters annotation on a method > - Semi-explicit: @ReifyParameters meta-annotation on a class annotation > - Semi-explicit: @ReifyParameters meta-annotation on a method annotation > - Implicit: Presence of any RUNTIME-retention annotation on a class > - Implicit: Presence of any RUNTIME-retention annotation on a method > - Implicit: Presence of any CLASS/RUNTIME-retention annotation on a class > - Implicit: Presence of any CLASS/RUNTIME-retention annotation on a > method > > Opinions differ on which is best. It seems risky at this time to > commit to one mechanism, since it would have to be supported forever > even if consensus comes round to a different mechanism. For this > reason, we will avoid defining a standard "opt in" mechanism for Java > SE 8. > > Alex From alex.buckley at oracle.com Mon Nov 12 14:49:00 2012 From: alex.buckley at oracle.com (Alex Buckley) Date: Mon, 12 Nov 2012 14:49:00 -0800 Subject: Spec updates for method parameter reflection In-Reply-To: <50A179B2.1050008@oracle.com> References: <509D680A.4070201@oracle.com> <509E4B55.60507@univ-mlv.fr> <50A149BA.6030706@oracle.com> <50A179B2.1050008@oracle.com> Message-ID: <50A17CDC.8090709@oracle.com> On 11/12/2012 2:35 PM, Leonid Arbouzov wrote: > What would be conformance requirements for this feature? Essentially: if the MethodParameters attribute is present in ClassFile of v52.0 or above, it must be interpreted by the reflection libraries of the Java SE platform in the appropriate way. The attribute has no effect on the runtime behavior of the attributed class itself. The attribute is much like the attributes for annotations. > For example, would a Java compiler be in conformance > with the spec in the following cases: > - the compiler generate parameter names by default for all classes (no > way to suppress it), Yes. > - the compiler ignores the option controlling parameter names generation > (no way to turn it on), Yes. (A compiler ignoring its own command-line option doesn't seem very well behaved though.) > - the compiler generate parameter names selectively (let's say for > public methods only), Yes. > - the compiler supports private (implementation-specific) annotations > controlling parameter names generation, Yes. The very strong traditional guidance is that an annotation must not cause the runtime behavior of code to differ from that specified in the JLS. It is acceptable if an annotation merely causes a MethodParameters attribute to be generated, because as above, the attribute does not affect the attributed's class runtime behavior. > - the compiler somehow modifies parameter names (let's say prefixing > with... "param_"). Yes. Since the reflection libraries have no source code available, they cannot prove that the parameter names being read from a MethodParameters attribute are anything other than what was in source. > BTW, compared with an option approach @ReifyParameters annotation > could allow more accurately specify and check Java compiler behavior > ...if it is important in that case. Yes. But we are deliberately avoiding an in-language mechanism (testable by a conformance suite) at this time. Alex From leonid.arbouzov at oracle.com Mon Nov 12 15:38:10 2012 From: leonid.arbouzov at oracle.com (Leonid Arbouzov) Date: Mon, 12 Nov 2012 15:38:10 -0800 Subject: Spec updates for method parameter reflection In-Reply-To: <50A17CDC.8090709@oracle.com> References: <509D680A.4070201@oracle.com> <509E4B55.60507@univ-mlv.fr> <50A149BA.6030706@oracle.com> <50A179B2.1050008@oracle.com> <50A17CDC.8090709@oracle.com> Message-ID: <50A18862.5020007@oracle.com> > Yes. (A compiler ignoring its own command-line option doesn't seem very well behaved though.) A compiler of XYZ company may want to ignore -g:parameters option of JDK's javac with well intentions - just trying to be more option compatible... Anyway, thanks for your answers. This makes it clear that the option indeed similar to -g option of javac and thus not a subject of Java compiler conformance testing... Could this create some compatibility problems? For example, one replaces Java+compiler version with other version and discovers that it's product fails at runtime because parameter names info missed? Would it be of any concern? Does it mean we care mostly about runtime compatibility in that case? Thanks, -leonid On 11/12/2012 2:49 PM, Alex Buckley wrote: > On 11/12/2012 2:35 PM, Leonid Arbouzov wrote: >> What would be conformance requirements for this feature? > > Essentially: if the MethodParameters attribute is present in ClassFile > of v52.0 or above, it must be interpreted by the reflection libraries > of the Java SE platform in the appropriate way. The attribute has no > effect on the runtime behavior of the attributed class itself. The > attribute is much like the attributes for annotations. > >> For example, would a Java compiler be in conformance >> with the spec in the following cases: >> - the compiler generate parameter names by default for all classes (no >> way to suppress it), > > Yes. > >> - the compiler ignores the option controlling parameter names generation >> (no way to turn it on), > > Yes. (A compiler ignoring its own command-line option doesn't seem > very well behaved though.) > >> - the compiler generate parameter names selectively (let's say for >> public methods only), > > Yes. > >> - the compiler supports private (implementation-specific) annotations >> controlling parameter names generation, > > Yes. The very strong traditional guidance is that an annotation must > not cause the runtime behavior of code to differ from that specified > in the JLS. It is acceptable if an annotation merely causes a > MethodParameters attribute to be generated, because as above, the > attribute does not affect the attributed's class runtime behavior. > >> - the compiler somehow modifies parameter names (let's say prefixing >> with... "param_"). > > Yes. Since the reflection libraries have no source code available, > they cannot prove that the parameter names being read from a > MethodParameters attribute are anything other than what was in source. > >> BTW, compared with an option approach @ReifyParameters annotation >> could allow more accurately specify and check Java compiler behavior >> ...if it is important in that case. > > Yes. But we are deliberately avoiding an in-language mechanism > (testable by a conformance suite) at this time. > > Alex From alex.buckley at oracle.com Mon Nov 12 15:58:15 2012 From: alex.buckley at oracle.com (Alex Buckley) Date: Mon, 12 Nov 2012 15:58:15 -0800 Subject: Spec updates for method parameter reflection In-Reply-To: <50A18862.5020007@oracle.com> References: <509D680A.4070201@oracle.com> <509E4B55.60507@univ-mlv.fr> <50A149BA.6030706@oracle.com> <50A179B2.1050008@oracle.com> <50A17CDC.8090709@oracle.com> <50A18862.5020007@oracle.com> Message-ID: <50A18D17.80100@oracle.com> On 11/12/2012 3:38 PM, Leonid Arbouzov wrote: > Anyway, thanks for your answers. > This makes it clear that the option indeed similar to -g option of javac > and thus not a subject of Java compiler conformance testing... > > Could this create some compatibility problems? > For example, one replaces Java+compiler version with > other version and discovers that it's product fails at runtime because > parameter names info missed? Would it be of any concern? > Does it mean we care mostly about runtime compatibility in that case? Compilers are free to put optional JVMS-defined attributes into class files today and it is up to the reflective client to handle their presence or absence. General questions of behavioral compatibility for the client are not the platform's concern. If attributes like MethodParameters or RuntimeVisibleAnnotations were once present in a class file, they may have been stripped (via pack200) by the time a client reflects over that class file. The java.lang.reflect API in such cases simply returns zero answers. Alex From forax at univ-mlv.fr Mon Nov 12 16:07:17 2012 From: forax at univ-mlv.fr (Remi Forax) Date: Tue, 13 Nov 2012 01:07:17 +0100 Subject: Spec updates for method parameter reflection In-Reply-To: <50A149BA.6030706@oracle.com> References: <509D680A.4070201@oracle.com> <509E4B55.60507@univ-mlv.fr> <50A149BA.6030706@oracle.com> Message-ID: <50A18F35.2010404@univ-mlv.fr> On 11/12/2012 08:10 PM, Alex Buckley wrote: > On 11/10/2012 4:40 AM, Remi Forax wrote: >> I think the default policy (don't include parameter names) is not the >> good one. While I agree that enable reified parameter everywhere can >> severely impact class file size (the runtime part can be lazy), there >> is a third option between enable and disable, enable parameter names >> selectively. >> >> I propose the following default policy, parameter names are enabled >> by default only if the methods is annotated with an annotation with >> the retention CLASS or RUNTIME. >> >> The idea is that if the method is annotated, the parameter names >> should be visible by a class enhancer or the reflection API. > > There are many ideas for an "opt in" mechanism: > > - Explicit: @ReifyParameters annotation on a class > - Explicit: @ReifyParameters annotation on a method > - Semi-explicit: @ReifyParameters meta-annotation on a class annotation > - Semi-explicit: @ReifyParameters meta-annotation on a method annotation I have thought about that ones (above) too. > - Implicit: Presence of any RUNTIME-retention annotation on a class > - Implicit: Presence of any RUNTIME-retention annotation on a method > - Implicit: Presence of any CLASS/RUNTIME-retention annotation on a class > - Implicit: Presence of any CLASS/RUNTIME-retention annotation on a > method > > Opinions differ on which is best. It seems risky at this time to > commit to one mechanism, since it would have to be supported forever > even if consensus comes round to a different mechanism. It's a question that should be asked during Devoxx, after all you have a lot of developer minds available during that week, a consensus may appear. > For this reason, we will avoid defining a standard "opt in" mechanism > for Java SE 8. If there is no default opt in, I think we should withdraw that feature from Java 8. There are two problems, if you don't provide a default, either nodoby will use it because it's no reliable, you can already extract local variable table from the bytecode, so you can have the name of the parameters, but because you need to opt-in to have debug information, it's not reliable for people that write bytecode enhancer or use reflection to implement meta protocols. Or the default opt-in will be vendors or tools specific, and it will be a mess. "Oh, you have compiled with ant/maven, that's why it doesn't work, you should use whateverIsTheNameOfTheVendorTool to enable EJB/REST/etc implementation to work". so if it's too hard to find a consensus on what should be the default opt-in, it's better to don't include that feature in Java 8, people will reify the parameter name by hands as they do now but at least it will work for everybody. > > Alex R?mi From pbenedict at apache.org Mon Nov 12 18:53:49 2012 From: pbenedict at apache.org (Paul Benedict) Date: Mon, 12 Nov 2012 20:53:49 -0600 Subject: Spec updates for method parameter reflection In-Reply-To: <50A18F35.2010404@univ-mlv.fr> References: <509D680A.4070201@oracle.com> <509E4B55.60507@univ-mlv.fr> <50A149BA.6030706@oracle.com> <50A18F35.2010404@univ-mlv.fr> Message-ID: On Mon, Nov 12, 2012 at 6:07 PM, Remi Forax wrote: > If there is no default opt in, I think we should withdraw that feature > from Java 8. > There are two problems, if you don't provide a default, either nodoby will > use it > because it's no reliable, you can already extract local variable table > from the bytecode, > so you can have the name of the parameters, but because you need to opt-in > to have debug information, it's not reliable for people that write > bytecode enhancer > or use reflection to implement meta protocols. > Or the default opt-in will be vendors or tools specific, and it will be a > mess. > "Oh, you have compiled with ant/maven, that's why it doesn't work, you > should use > whateverIsTheNameOfTheVendorTo**ol to enable EJB/REST/etc implementation > to work". > > I think whatever Oracle chooses will be a trendsetter. If Oracle values smaller class files over storing parameter names as a default, developers will follow the lead and not rely on the information ever being present. You might as well not provide the feature. It's not realistically useful if the extra metadata is optional. Paul From alex.buckley at oracle.com Mon Nov 12 19:12:49 2012 From: alex.buckley at oracle.com (Alex Buckley) Date: Mon, 12 Nov 2012 19:12:49 -0800 Subject: Spec updates for method parameter reflection In-Reply-To: References: <509D680A.4070201@oracle.com> <509E4B55.60507@univ-mlv.fr> <50A149BA.6030706@oracle.com> <50A18F35.2010404@univ-mlv.fr> Message-ID: <50A1BAB1.3010705@oracle.com> On 11/12/2012 6:53 PM, Paul Benedict wrote: > I think whatever Oracle chooses will be a trendsetter. If Oracle values > smaller class files over storing parameter names as a default, developers > will follow the lead and not rely on the information ever being present. > You might as well not provide the feature. It's not realistically useful if > the extra metadata is optional. If you follow build-infra-dev, you will see me there asking for the build system to compile JDK8 _with_ parameter names in the common case. The problem in the common (non-Embedded) case is not class file size. It's not even exposing formerly-private names, not really. The problem is that no-one agrees on the opt-in mechanism. By all means run a whiteboard poll at Devoxx but it's fundamentally a syntax question so everyone has an opinion and every opinion has pro's and con's. Inside Oracle we have found agreement on not committing to a language mechanism in SE 8 - but we will still get all the plumbing in place (java.lang.reflect.Parameter is a lot nicer than walking LocalVariableTable with ASM). Alex From reinier at zwitserloot.com Mon Nov 26 13:22:29 2012 From: reinier at zwitserloot.com (Reinier Zwitserloot) Date: Mon, 26 Nov 2012 22:22:29 +0100 Subject: There's cake! Message-ID: I must echo Paul's sentiments here: Are we really about burden the future of java _forever_ just to cater to existing containers? Eh, no worries: There's a way to simplify this proposal considerably and yet continue to support these. Yep, we can have our cake, and eat it too. Before I continue with a proposal to (vastly!) improve the spec, I'd like to state my assumptions here: * According to the Java EE team, there is significant use of container annotations out there, and we should not just rely on these libraries to use deprecation mechanisms to migrate away from them. In short: .get(Declared)Annotation(SomeExplicitlyDefinedContainerAnnotation.class) needs to continue to work even if some element is annotated with `@Foo(1) @Foo(2)` instead of `@FooContainer({@Foo(1), @Foo(2)})`. * Burdening the future of java with (other than preserving backwards compatibility) container annotations that have to be explicitly defined and which are public API is a extremely high cost to pay, and something we should strive to avoid at all costs. It is clear to me that we should try to find a way to have our cake and eat it to: Ditch the concept of container annotations entirely, and yet, allow already existing containers to continue to work. This seems easy to do. The proposal to make this work is as follows: * Allow multiple annotations to be supported in the most natural way possible: `@Foo(1) @Foo(2)` is compiled to simply having two @Foo annotation blocks in the class file; absolutely no need for @ContainedBy, nor for any explicit or implicit container annotation. The reflection API implementations become much simpler as a result as the 'weird' scenarios where there is a mix of the annotation itself and its container annotation all disappear. To allow user control of cardinality, a '@Repeatable' meta annotation can be created to signal that some annotation can be repeated on its target elements. * To continue to support explicit container annotations, we add the following feature to the reflective APIs: _IF_ any annotation is annotated with `@ContainerFor(A.class)`, _AND_ there is a request for this specific annotation, e.g. .getAnnotation(FooContainer.class), _AND_ the result _would_ be null (i.e. there is no @FooContainer on the element at all), _AND_ at least one annotation of type A is present, then then the reflection API will provide an instance of FooContainer anyway, filling the value() array with each instance of A on the chosen element. The same rules apply here (such as: The return type of the value() method must be A[]) as in the current version of the proposal. The above proposal has every advantage of the current proposal and almost none of its considerable disadvantages. to wit: * The library author must update the container annotation explicitly. This is true both in the current proposal (@ContainerFor must be added), as it is in this new proposal (@ContainerFor must also be added). * In the new proposal, there is absolutely no need for a container of any sort for any new API which is built for java8+. In the current proposal, when containers should have been a distant memory, we'll be stuck with them forever. * Unavoidably surprising behavior occurs when you mix the container and the base annotation. In the current proposal, the answer given by the reflection API sometimes changes between JDK7 and JDK8 and sometimes it doesn't. In this proposal, backwards compatibility actually improves: .getAnnotation(SomeContainer.class) will give the exact same answer, by definition, as JDK7's answer, _UNLESS_ that answer would be 'null'. For example, in the current proposal, @Inherit can change the rules, and result in a different answer: @FooContainer(@Foo(0)) public class A {} @Foo(1) public class B extends A {} Asking for .getAnnotations() will return just @Foo(1) and nothing else; in JDK7, you'd get both @FooContainer and @Foo. In my proposal, you get the same answer as JDK7. Again, the one and only backwards incompatible change is that _IF_ the answer _WOULD_ be null, then instead you get a generated answer. The practical upshot is very simple: * Developers of new APIs, or anybody who has an aggressive deprecation policy forgets entirely about the idea of containers or removes them from their API, and gets the benefit of a much simpler reflection API forever. They do not have the burden of having to maintain a public container annotation. * Developers of existing APIs stick a '@ContainerFor' on their container, @Repeatable on the base annotation, and continue to publish this container forever. Their code uses .getAnnotation(FooContainer.class) and reads that annotation's value() method instead of ever using .getAnnotations(Foo.class). This actually means they get to keep using their current code instead of changing to a new API!. It's win, win. --Reinier Zwitserloot From reinier at zwitserloot.com Mon Nov 26 13:55:54 2012 From: reinier at zwitserloot.com (Reinier Zwitserloot) Date: Mon, 26 Nov 2012 22:55:54 +0100 Subject: Some smallish comments on the current version of the spec. Message-ID: "@ContainerFor supports the java SE platform reflection?" - This paragraph seems to make the point that it is important to differentiate @FooContainer({@Foo(1), @Foo(2)}) from just @Foo(1) @Foo(2). Why is this relevant? Also, later on, the examples of how JDK8 answers .get(Declared)Annotation queries indicates that differentiating these two cases in not actually important. That leaves the question of: Why is @ContainerFor needed in the first place? "@ContainerFor" itself: While the stated aim is to be as compatible with existing containers as possible, there are now 2 restrictions: * The container method must be "value()". * All other methods must have a default. There are also many DRY violations: There's both @ContainerFor and @ContainedBy, _AND_ in the container annotation, the base type is repeated. At the very least, it is possible to eliminate both the value() restriction and one repetition of the base type by getting rid of @ContainerFor and introducing the @Container marker annotation. This annotation goes on a method in an annotation declaration and signals that this is the container method, i.e. that the return type of this method must be A[], and it means that the containing annotation is a container for A. There must be at most 1 @Container annotation, and all other methods must have a default. In other words, instead of: @ContainerFor(Foo.class) @interface FooContainer { Foo[] value(); } We get: @interface FooContainer { @Container Foo[] whatever(); } --Reinier Zwitserloot From alex.buckley at oracle.com Mon Nov 26 15:10:17 2012 From: alex.buckley at oracle.com (Alex Buckley) Date: Mon, 26 Nov 2012 15:10:17 -0800 Subject: There's cake! In-Reply-To: References: Message-ID: <50B3F6D9.4050704@oracle.com> Hi Reinier, Obviously, a world without container annotations is much simpler, but we are stuck with them. In terms of how your proposal handles them, I note that: - It still requires the containing annotation type to be marked (@ContainerFor(A.class)) for the benefit of legacy clients. - It still requires a sensible relationship between the containing and repeatable annotation types. (For example, it would be silly to allow getAnnotation(FooContainer.class) to succeed auto-magically if FooContainer.class truly exists and has @Retention(SOURCE).) - It still requires "look through" by the core reflection and language model APIs when presented with legacy class files that physically have container annotations. - It has the same compatibility impact at runtime for the common case (Example 1.2-1), namely the exposure of multiple annotations of the same type. (Frankly, I expect the last point to cause far more teeth-gnashing than the container/containee relationship, since only the API owner sets that relationship whereas untold numbers of clients are affected by behavioral incompatibility. We considered having the SE 7 reflection methods behave identically in SE 8 to SE 7, but decided instead to make the methods "do the right thing" in SE 8 and beyond - the language allows multiple annotations of the same type, so reflection should too.) All of the above makes me think there is very little simplification in your proposal. You've just changed the "opt in" flag from @ContainedBy(...) to @Repeatable. And there are two downsides: - Since the Foo type is just "repeatable", there is no control over _where_ @Foo may be repeated. It is an important aspect of the Oracle proposal that the annotation type owner controls the kinds of declarations (classes, fields, etc) on which their annotation may occur more than once (via @Target on the containing annotation type). - Your reflection behavior is to synthesize a container annotation only if the client asks for one and there's at least one base annotation present. A legacy client may legitimately expect to find @FooContainer with an _empty_ value(), but no such annotation will be synthesized. I also suspect the rules for container synthesis are more complex than presently thought. The current design has been publicly specified for over three months and the implementation is pretty much complete, so it's a bit late to redesign things. An orthogonal issue is reflection over a mix of base and container annotations. There is a deliberate policy laid out in section 1.2 that @Foo(1) on the subclass hides @Foo(0) (whether contained or not) on the superclass. Under a different policy, where no Foo hiding occurs, we would still "look through" @FooContainer and return @Foo(0) from the superclass + @Foo(1) from the subclass. I am surprised you think that getAnnotations() in SE 8 should ever return a container. Again, Oracle is happy to propose that SE 7 methods like getAnnotations() change behavior if it's "the right thing" going forward. Alex On 11/26/2012 1:22 PM, Reinier Zwitserloot wrote: > I must echo Paul's sentiments here: Are we really about burden the future > of java _forever_ just to cater to existing containers? > > Eh, no worries: There's a way to simplify this proposal considerably and > yet continue to support these. Yep, we can have our cake, and eat it too. > > Before I continue with a proposal to (vastly!) improve the spec, I'd like > to state my assumptions here: > > * According to the Java EE team, there is significant use of container > annotations out there, and we should not just rely on these libraries to > use deprecation mechanisms to migrate away from them. In short: > .get(Declared)Annotation(SomeExplicitlyDefinedContainerAnnotation.class) > needs to continue to work even if some element is annotated with `@Foo(1) > @Foo(2)` instead of `@FooContainer({@Foo(1), @Foo(2)})`. > > * Burdening the future of java with (other than preserving backwards > compatibility) container annotations that have to be explicitly defined and > which are public API is a extremely high cost to pay, and something we > should strive to avoid at all costs. > > > It is clear to me that we should try to find a way to have our cake and eat > it to: Ditch the concept of container annotations entirely, and yet, allow > already existing containers to continue to work. > > This seems easy to do. The proposal to make this work is as follows: > > * Allow multiple annotations to be supported in the most natural way > possible: `@Foo(1) @Foo(2)` is compiled to simply having two @Foo > annotation blocks in the class file; absolutely no need for @ContainedBy, > nor for any explicit or implicit container annotation. The reflection API > implementations become much simpler as a result as the 'weird' scenarios > where there is a mix of the annotation itself and its container annotation > all disappear. To allow user control of cardinality, a '@Repeatable' meta > annotation can be created to signal that some annotation can be repeated on > its target elements. > > * To continue to support explicit container annotations, we add the > following feature to the reflective APIs: _IF_ any annotation is annotated > with `@ContainerFor(A.class)`, _AND_ there is a request for this specific > annotation, e.g. .getAnnotation(FooContainer.class), _AND_ the result > _would_ be null (i.e. there is no @FooContainer on the element at all), > _AND_ at least one annotation of type A is present, then then the > reflection API will provide an instance of FooContainer anyway, filling the > value() array with each instance of A on the chosen element. The same rules > apply here (such as: The return type of the value() method must be A[]) as > in the current version of the proposal. > > > The above proposal has every advantage of the current proposal and almost > none of its considerable disadvantages. to wit: > > * The library author must update the container annotation explicitly. This > is true both in the current proposal (@ContainerFor must be added), as it > is in this new proposal (@ContainerFor must also be added). > > * In the new proposal, there is absolutely no need for a container of any > sort for any new API which is built for java8+. In the current proposal, > when containers should have been a distant memory, we'll be stuck with them > forever. > > * Unavoidably surprising behavior occurs when you mix the container and the > base annotation. In the current proposal, the answer given by the > reflection API sometimes changes between JDK7 and JDK8 and sometimes it > doesn't. In this proposal, backwards compatibility actually improves: > .getAnnotation(SomeContainer.class) will give the exact same answer, by > definition, as JDK7's answer, _UNLESS_ that answer would be 'null'. For > example, in the current proposal, @Inherit can change the rules, and result > in a different answer: > > @FooContainer(@Foo(0)) public class A {} > @Foo(1) public class B extends A {} > > Asking for .getAnnotations() will return just @Foo(1) and nothing else; in > JDK7, you'd get both @FooContainer and @Foo. In my proposal, you get the > same answer as JDK7. > > Again, the one and only backwards incompatible change is that _IF_ the > answer _WOULD_ be null, then instead you get a generated answer. > > The practical upshot is very simple: > > * Developers of new APIs, or anybody who has an aggressive deprecation > policy forgets entirely about the idea of containers or removes them from > their API, and gets the benefit of a much simpler reflection API forever. > They do not have the burden of having to maintain a public container > annotation. > > * Developers of existing APIs stick a '@ContainerFor' on their container, > @Repeatable on the base annotation, and continue to publish this container > forever. Their code uses .getAnnotation(FooContainer.class) and reads that > annotation's value() method instead of ever using > .getAnnotations(Foo.class). This actually means they get to keep using > their current code instead of changing to a new API!. > > It's win, win. > > --Reinier Zwitserloot > From alex.buckley at oracle.com Mon Nov 26 16:24:26 2012 From: alex.buckley at oracle.com (Alex Buckley) Date: Mon, 26 Nov 2012 16:24:26 -0800 Subject: Some smallish comments on the current version of the spec. In-Reply-To: References: Message-ID: <50B4083A.9060208@oracle.com> On 11/26/2012 1:55 PM, Reinier Zwitserloot wrote: > "@ContainerFor supports the java SE platform reflection?" - This paragraph > seems to make the point that it is important to differentiate > @FooContainer({@Foo(1), @Foo(2)}) from just @Foo(1) @Foo(2). Why is this > relevant? Also, later on, the examples of how JDK8 answers > .get(Declared)Annotation queries indicates that differentiating these two > cases in not actually important. That leaves the question of: Why is > @ContainerFor needed in the first place? This was discussed in August in the list's very first thread. > "@ContainerFor" itself: While the stated aim is to be as compatible with > existing containers as possible, there are now 2 restrictions: > > * The container method must be "value()". > * All other methods must have a default. > > There are also many DRY violations: There's both @ContainerFor and > @ContainedBy, _AND_ in the container annotation, the base type is repeated. > At the very least, it is possible to eliminate both the value() restriction > and one repetition of the base type by getting rid of @ContainerFor and > introducing the @Container marker annotation. This is a reasonable suggestion, though probably too late. Alex From reinier at zwitserloot.com Mon Nov 26 16:54:41 2012 From: reinier at zwitserloot.com (Reinier Zwitserloot) Date: Tue, 27 Nov 2012 01:54:41 +0100 Subject: There's cake! In-Reply-To: <50B3F6D9.4050704@oracle.com> References: <50B3F6D9.4050704@oracle.com> Message-ID: On Tue, Nov 27, 2012 at 12:10 AM, Alex Buckley wrote: > > - It still requires the containing annotation type to be marked > (@ContainerFor(A.class)) for the benefit of legacy clients. > > Correct, but the key difference is that you don't _NEED_ to make a containing annotation type in the first place! In my proposal, containers as a concept exists only as a way to grandfather in existing containers. It's not something anybody building a new library should even touch. Misc8 _REQUIRES_ the creation of one (by hand!). Forever. Like Paul said, forcing the use of containers forever from here on out seems very shortsighted, especially for a feature (annotations) that isn't very old. My proposal is roughly equivalent for existing libraries, and much simpler for new ones. > - It still requires a sensible relationship between the containing and > repeatable annotation types. (For example, it would be silly to allow > getAnnotation(FooContainer.**class) to succeed auto-magically if > FooContainer.class truly exists and has @Retention(SOURCE).) > Why not? If FooContainer is _explicitly_ marked to be the container for @Foo, then I don't see any issue with x.getAnnotation(FooContainer.class) resulting in a generated FooContainer instance that is simply an aggregator for all the @Foos on 'x', even if FooContainer somehow ends up with @Retention(SOURCE). Alternatively, Marking an annotation declaration with both source retention and @ContainerFor can be considered a compiler error; if you want I can write up a spec that just makes a heads-or-tails call on these issues, because there are pros and cons for either scenario. I thought it would be more fruitful to consider the basics first before delving in such detail. The relation is that FooContainer is marked @ContainerFor(Foo.class). No further relations are necessary. > > - It still requires "look through" by the core reflection and language > model APIs when presented with legacy class files that physically have > container annotations. > That is mostly correct; my proposal still requires look-through. It requires less of that, though: The code remains unchanged (other than adapting to be able to handle multiple annotations of the same type in the class file format itself), but, if the result is not found (i.e., return null in the current implementation), instead check if the asked-for annotation has a @ContainerFor annotation, and if so, create a proxy for that if there is at least one base annotation present. As far as implementing goes, my proposal does not significantly cut down on effort. The aim is to turn all this extra effort into something that is relevant only for the current crop of containers. Any new APIs (and any existing libraries that deprecate their containers) don't even need to know any of this functionality to cater to backwards compatibility exists. As I said, my proposal is roughly equivalent for existing libraries, and much simpler for new ones. So far, we're still on things that are only relevant for existing libraries. For new libraries, there's just a simple one-liner added: Instead of the process: "No annotations found, so, return null", we get: "No annotations found, so, does this annotation declaration have @ContainerFor on it? No? Then, return null". I can't imagine this is going to be a problem. > > - It has the same compatibility impact at runtime for the common case > (Example 1.2-1), namely the exposure of multiple annotations of the same > type. > > the same... for existing libraries! For _new_ libraries, this complexity goes away entirely, because _there is no container_. at all. No container means no 1.2-1. My proposal is roughly equivalent for existing libraries, and much simpler for new ones. (Frankly, I expect the last point to cause far more teeth-gnashing than the > container/containee relationship, since only the API owner sets that > relationship whereas untold numbers of clients are affected by behavioral > incompatibility. We considered having the SE 7 reflection methods behave > identically in SE 8 to SE 7, but decided instead to make the methods "do > the right thing" in SE 8 and beyond - the language allows multiple > annotations of the same type, so reflection should too.) > I'm not sure I follow. There are two base cases: * A library featuring repeatable annotations is new or aggressively deprecates and as such has no container whatsoever. As this can only possibly work in JavaSE8+, the library only runs on JavaSE8+, and thus uses .getAnnotations(Base.class). There are no weird corner cases when both the container and the base are present - my proposal has vastly simplified matters. * A library featuring repeatable annotations decides to use a container. There is only one reason to do this: This library already had a container, i.e., this library was written to run on JavaSE7. Any simplification of the API in JavaSE8 is irrelevant; in fact, changing the answers that the existing reflection API calls give, even if the new answers are easier to work with, can only serve to make life harder for the developers of this library: They _HAVE TO_ run on JavaSE7, and thus they _HAVE TO_ handle the answers JavaSE7 can give. This includes answering with a container if you call .getAnnotations() and a container is explicitly present. If a library decides to migrate such that it is no longer compatible with JavaSE7, it can do so very easily: Get rid of the container, and use .getAnnotations(Base.class). My proposal is in all cases easier for both library authors and end users compared to Misc 8(for the 'new library' case, significantly so). > All of the above makes me think there is very little simplification in > your proposal. You've just changed the "opt in" flag from @ContainedBy(...) > to @Repeatable. And there are two downsides: > I'm very confused now. My proposal completely eliminates the need for the container, and with it, the considerable complexity that that entails, for all users. That seems like quite a big deal to me! New library authors get the benefit of no containers immediately. Existing libraries that already have containers can give their end users a nice bit of syntax sugar immediately without having to change their code at all, and can deprecate their container whenever their schedule allows them to do so. In the worst case scenario, where there is no plan to ever migrate away from the container, my proposal is not better, but also not worse, than Misc8. > > - Since the Foo type is just "repeatable", there is no control over > _where_ @Foo may be repeated. It is an important aspect of the Oracle > proposal that the annotation type owner controls the kinds of declarations > (classes, fields, etc) on which their annotation may occur more than once > (via @Target on the containing annotation type). > What are the use cases for this? If there are valid use cases, @Repeatable can also be granted the ElementType parameter similar to @Target. This is another detail I intentionally left out, as it is trivially solvable and does not seem pertinent to the central idea of what I'm proposing. At any rate, listing the types where repeatability is allowed directly on the base annotation seems a lot nicer compared to having to look up the container and then checking the @Target on that. > > - Your reflection behavior is to synthesize a container annotation only if > the client asks for one and there's at least one base annotation present. A > legacy client may legitimately expect to find @FooContainer with an _empty_ > value(), but no such annotation will be synthesized. I also suspect the > rules for container synthesis are more complex than presently thought. > Good point; as @ContainerFor must be explicitly added, the API for .getAnnotation(SomeContainer.class) should be defined as returning a synthesized SomeContainer instance with an empty value() if no base annotations are found at all. I don't follow how container synthesis is more complex compared to the Misc8 proposal; after all, Misc8 synthesizes containers in exactly the same way; it just does so at compile time, and not at run time. However, because it requires asking for one 'by name', so to speak, the container class is guaranteed present at runtime. I don't understand why this would be more complicated compared to doing the same thing at compile time. The empty file issue can be worked around. The simplest way is to state that @FooContainer will be synthesized with _empty_ value() if it is not present but FooContainer (the declaration) is marked with @ContainerFor. The library has to explicitly add the @ContainerFor, after all. Every method in the annotation declaration returns its default (as defaults must be present for everything except the value() method). What complications do you foresee in returning defaults? The reflective API can already do this with .getDefaultValue() on the j.l.r.Method object right now. The value() method needs to return a synthesized array which is the exact same as the output of .getAnnotations(Base.class). What other complications do you suspect? > > The current design has been publicly specified for over three months and > the implementation is pretty much complete, so it's a bit late to redesign > things. > Repeatable annotations is a proposal that avoids a slight bit of boilerplate. It does not enable anything that cannot be done right now with containers. It does not strike me, in the slightest, as a crucial aspect of java8 whose lack will be sorely missed. With a proposal on the table that at least appears to result in a markedly less complicated end result (in that the entire concept of 'containers' can just go away for everyone that hasn't already built one), it seems crazy to me to continue just because of time pressure. > An orthogonal issue is reflection over a mix of base and container > annotations. There is a deliberate policy laid out in section 1.2 that > @Foo(1) on the subclass hides @Foo(0) (whether contained or not) on the > superclass. Under a different policy, where no Foo hiding occurs, we would > still "look through" @FooContainer and return @Foo(0) from the superclass + > @Foo(1) from the subclass. I am surprised you think that getAnnotations() > in SE 8 should ever return a container. Again, Oracle is happy to propose > that SE 7 methods like getAnnotations() change behavior if it's "the right > thing" going forward. > > You're surprised I'm in favour of not changing the behaviour of existing API? That's unexpected. Any library that has containers in the first place is designed to work with JavaSE7, and JavaSE7 will return containers when calling .getAnnotations(). We can't go back in time and change JavaSE7's spec. Not changing spec is a superior solution for these libraries. Any library that is not designed to work with JavaSE7 will (with my proposal) not use containers. Without containers, .getAnnotations() couldn't possibly return one. Not even introducing the notion of containers in the first place is a superior solution for these libraries. -- Reinier Zwitserloot From reinier at zwitserloot.com Tue Nov 27 13:10:28 2012 From: reinier at zwitserloot.com (Reinier Zwitserloot) Date: Tue, 27 Nov 2012 22:10:28 +0100 Subject: Some smallish comments on the current version of the spec. In-Reply-To: <50B4083A.9060208@oracle.com> References: <50B4083A.9060208@oracle.com> Message-ID: A spec is posted for 3 months and it's too late for further commentary? I feel like I'm in a Douglas Adams sketch. I get the feeling 'too late' would have been the answer if I posted these comments 5 minutes after this list was created; the very first post explains how lots had already been done. It's language design. Specs cannot change (easily). Surely "Do it right" wins over "release quickly". This spec is riddled with concessions in the interest of speed-of-release. It would be nice if the spec included a section explaining what's on fire, because this spec does not strike me as something that needs to be pushed out, half-baked. Between this and my earlier commentary on how it is not neccessary to burden the language with boilerplatey workarounds -forever- (containers), 'half-baked' seems appropriate. --Reinier Zwitserloot On Tue, Nov 27, 2012 at 1:24 AM, Alex Buckley wrote: > On 11/26/2012 1:55 PM, Reinier Zwitserloot wrote: > >> "@ContainerFor supports the java SE platform reflection?" - This paragraph >> seems to make the point that it is important to differentiate >> @FooContainer({@Foo(1), @Foo(2)}) from just @Foo(1) @Foo(2). Why is this >> relevant? Also, later on, the examples of how JDK8 answers >> .get(Declared)Annotation queries indicates that differentiating these two >> cases in not actually important. That leaves the question of: Why is >> @ContainerFor needed in the first place? >> > > This was discussed in August in the list's very first thread. > > > "@ContainerFor" itself: While the stated aim is to be as compatible with >> existing containers as possible, there are now 2 restrictions: >> >> * The container method must be "value()". >> * All other methods must have a default. >> >> There are also many DRY violations: There's both @ContainerFor and >> @ContainedBy, _AND_ in the container annotation, the base type is >> repeated. >> At the very least, it is possible to eliminate both the value() >> restriction >> and one repetition of the base type by getting rid of @ContainerFor and >> introducing the @Container marker annotation. >> > > This is a reasonable suggestion, though probably too late. > > Alex > From alex.buckley at oracle.com Tue Nov 27 13:45:45 2012 From: alex.buckley at oracle.com (Alex Buckley) Date: Tue, 27 Nov 2012 13:45:45 -0800 Subject: Some smallish comments on the current version of the spec. In-Reply-To: References: <50B4083A.9060208@oracle.com> Message-ID: <50B53489.3020703@oracle.com> You're mixing my comments from the other thread with the specific responses I gave in this thread. Please don't do that. I will respond in the other thread when I have a chance. Alex On 11/27/2012 1:10 PM, Reinier Zwitserloot wrote: > A spec is posted for 3 months and it's too late for further commentary? > I feel like I'm in a Douglas Adams sketch. > > I get the feeling 'too late' would have been the answer if I posted > these comments 5 minutes after this list was created; the very first > post explains how lots had already been done. > > It's language design. Specs cannot change (easily). Surely "Do it right" > wins over "release quickly". This spec is riddled with concessions in > the interest of speed-of-release. It would be nice if the spec included > a section explaining what's on fire, because this spec does not strike > me as something that needs to be pushed out, half-baked. > > Between this and my earlier commentary on how it is not neccessary to > burden the language with boilerplatey workarounds -forever- > (containers), 'half-baked' seems appropriate. > > --Reinier Zwitserloot > > > > On Tue, Nov 27, 2012 at 1:24 AM, Alex Buckley > wrote: > > On 11/26/2012 1:55 PM, Reinier Zwitserloot wrote: > > "@ContainerFor supports the java SE platform reflection?" - This > paragraph > seems to make the point that it is important to differentiate > @FooContainer({@Foo(1), @Foo(2)}) from just @Foo(1) @Foo(2). Why > is this > relevant? Also, later on, the examples of how JDK8 answers > .get(Declared)Annotation queries indicates that differentiating > these two > cases in not actually important. That leaves the question of: Why is > @ContainerFor needed in the first place? > > > This was discussed in August in the list's very first thread. > > > "@ContainerFor" itself: While the stated aim is to be as > compatible with > existing containers as possible, there are now 2 restrictions: > > * The container method must be "value()". > * All other methods must have a default. > > There are also many DRY violations: There's both @ContainerFor and > @ContainedBy, _AND_ in the container annotation, the base type > is repeated. > At the very least, it is possible to eliminate both the value() > restriction > and one repetition of the base type by getting rid of > @ContainerFor and > introducing the @Container marker annotation. > > > This is a reasonable suggestion, though probably too late. > > Alex > > From reinier at zwitserloot.com Tue Nov 27 15:21:31 2012 From: reinier at zwitserloot.com (Reinier Zwitserloot) Date: Wed, 28 Nov 2012 00:21:31 +0100 Subject: Some smallish comments on the current version of the spec. In-Reply-To: <50B53489.3020703@oracle.com> References: <50B4083A.9060208@oracle.com> <50B53489.3020703@oracle.com> Message-ID: No, my comments are focused entirely on the snippet: "Probably too late". That sentence should not be uttered in language spec design. Especially not when "... you had 3 months" and "that's a good point" preceded it. --Reinier Zwitserloot On Tue, Nov 27, 2012 at 10:45 PM, Alex Buckley wrote: > You're mixing my comments from the other thread with the specific > responses I gave in this thread. Please don't do that. I will respond in > the other thread when I have a chance. > > Alex > > > On 11/27/2012 1:10 PM, Reinier Zwitserloot wrote: > >> A spec is posted for 3 months and it's too late for further commentary? >> I feel like I'm in a Douglas Adams sketch. >> >> I get the feeling 'too late' would have been the answer if I posted >> these comments 5 minutes after this list was created; the very first >> post explains how lots had already been done. >> >> It's language design. Specs cannot change (easily). Surely "Do it right" >> wins over "release quickly". This spec is riddled with concessions in >> the interest of speed-of-release. It would be nice if the spec included >> a section explaining what's on fire, because this spec does not strike >> me as something that needs to be pushed out, half-baked. >> >> Between this and my earlier commentary on how it is not neccessary to >> burden the language with boilerplatey workarounds -forever- >> (containers), 'half-baked' seems appropriate. >> >> --Reinier Zwitserloot >> >> >> >> On Tue, Nov 27, 2012 at 1:24 AM, Alex Buckley > >> wrote: >> >> On 11/26/2012 1:55 PM, Reinier Zwitserloot wrote: >> >> "@ContainerFor supports the java SE platform reflection?" - This >> paragraph >> seems to make the point that it is important to differentiate >> @FooContainer({@Foo(1), @Foo(2)}) from just @Foo(1) @Foo(2). Why >> is this >> relevant? Also, later on, the examples of how JDK8 answers >> .get(Declared)Annotation queries indicates that differentiating >> these two >> cases in not actually important. That leaves the question of: Why >> is >> @ContainerFor needed in the first place? >> >> >> This was discussed in August in the list's very first thread. >> >> >> "@ContainerFor" itself: While the stated aim is to be as >> compatible with >> existing containers as possible, there are now 2 restrictions: >> >> * The container method must be "value()". >> * All other methods must have a default. >> >> There are also many DRY violations: There's both @ContainerFor and >> @ContainedBy, _AND_ in the container annotation, the base type >> is repeated. >> At the very least, it is possible to eliminate both the value() >> restriction >> and one repetition of the base type by getting rid of >> @ContainerFor and >> introducing the @Container marker annotation. >> >> >> This is a reasonable suggestion, though probably too late. >> >> Alex >> >> >> From alex.buckley at oracle.com Tue Nov 27 15:41:18 2012 From: alex.buckley at oracle.com (Alex Buckley) Date: Tue, 27 Nov 2012 15:41:18 -0800 Subject: Some smallish comments on the current version of the spec. In-Reply-To: References: <50B4083A.9060208@oracle.com> <50B53489.3020703@oracle.com> Message-ID: <50B54F9E.8050303@oracle.com> If that's the scope of "too late", then I can promise you that a method-level @Container annotation would _not_ have been "too late" if suggested three months ago. It's a good, tightly-scoped idea. But you didn't comment three months ago, and now the feature is done, sorry. Alex On 11/27/2012 3:21 PM, Reinier Zwitserloot wrote: > No, my comments are focused entirely on the snippet: "Probably too > late". That sentence should not be uttered in language spec design. > Especially not when "... you had 3 months" and "that's a good point" > preceded it. > > --Reinier Zwitserloot > > > > On Tue, Nov 27, 2012 at 10:45 PM, Alex Buckley > wrote: > > You're mixing my comments from the other thread with the specific > responses I gave in this thread. Please don't do that. I will > respond in the other thread when I have a chance. > > Alex > > > On 11/27/2012 1:10 PM, Reinier Zwitserloot wrote: > > A spec is posted for 3 months and it's too late for further > commentary? > I feel like I'm in a Douglas Adams sketch. > > I get the feeling 'too late' would have been the answer if I posted > these comments 5 minutes after this list was created; the very first > post explains how lots had already been done. > > It's language design. Specs cannot change (easily). Surely "Do > it right" > wins over "release quickly". This spec is riddled with > concessions in > the interest of speed-of-release. It would be nice if the spec > included > a section explaining what's on fire, because this spec does not > strike > me as something that needs to be pushed out, half-baked. > > Between this and my earlier commentary on how it is not > neccessary to > burden the language with boilerplatey workarounds -forever- > (containers), 'half-baked' seems appropriate. > > --Reinier Zwitserloot > > > > On Tue, Nov 27, 2012 at 1:24 AM, Alex Buckley > > >> wrote: > > On 11/26/2012 1:55 PM, Reinier Zwitserloot wrote: > > "@ContainerFor supports the java SE platform > reflection?" - This > paragraph > seems to make the point that it is important to > differentiate > @FooContainer({@Foo(1), @Foo(2)}) from just @Foo(1) > @Foo(2). Why > is this > relevant? Also, later on, the examples of how JDK8 answers > .get(Declared)Annotation queries indicates that > differentiating > these two > cases in not actually important. That leaves the > question of: Why is > @ContainerFor needed in the first place? > > > This was discussed in August in the list's very first thread. > > > "@ContainerFor" itself: While the stated aim is to be as > compatible with > existing containers as possible, there are now 2 > restrictions: > > * The container method must be "value()". > * All other methods must have a default. > > There are also many DRY violations: There's both > @ContainerFor and > @ContainedBy, _AND_ in the container annotation, the > base type > is repeated. > At the very least, it is possible to eliminate both the > value() > restriction > and one repetition of the base type by getting rid of > @ContainerFor and > introducing the @Container marker annotation. > > > This is a reasonable suggestion, though probably too late. > > Alex > > > From r.spilker at gmail.com Wed Nov 28 06:13:15 2012 From: r.spilker at gmail.com (Roel Spilker) Date: Wed, 28 Nov 2012 15:13:15 +0100 Subject: JSR for Repeating Annotations language change Message-ID: Hi Alex, Can you tell me what JSR covers the language change regarding repeating annotations? I looked at the list of JSRs at http://jcp.org/en/jsr/all but could not identify the right JSR based on their descriptions. Roel From reinier at zwitserloot.com Wed Nov 28 06:13:27 2012 From: reinier at zwitserloot.com (Reinier Zwitserloot) Date: Wed, 28 Nov 2012 15:13:27 +0100 Subject: Some smallish comments on the current version of the spec. In-Reply-To: <50B54F9E.8050303@oracle.com> References: <50B4083A.9060208@oracle.com> <50B53489.3020703@oracle.com> <50B54F9E.8050303@oracle.com> Message-ID: Okay, so you're going on record that it's official policy to knowingly run with a clearly half-baked proposal, closing the door on any further review a scant 3 months after posting a specification (which had already been mostly implemented at that point according to the first post on this list). Not just that, there isn't even an explanation for why this feature is so incredibly important that it must be released right now, half-baked. This feature seems like the opposite: It enables nothing that can't already be done with JDK7. It feels like a coin improvement: Nice syntax sugar but that's it. _THIS_ is getting rushed? That's surprising, and I cannot find words to express how incredibly disappointed I am. Combining java's dedication to backwards compatibility with rushed ill-considered specs for no clearly stated reason... do I really need to explain how that sounds like a truly horrible plan? There is a very serious cost associated with carrying on with this proposal oblivious to the issues that surround it: There are ways to do this right, but by pushing ahead now, you're closing the door on these forever. It's java.util.Date + java.util.Calendar, except at the JLS level. Please, pretty please, with sugar on top, reconsider. From pbenedict at apache.org Wed Nov 28 06:56:34 2012 From: pbenedict at apache.org (Paul Benedict) Date: Wed, 28 Nov 2012 08:56:34 -0600 Subject: Some smallish comments on the current version of the spec. In-Reply-To: References: <50B4083A.9060208@oracle.com> <50B53489.3020703@oracle.com> <50B54F9E.8050303@oracle.com> Message-ID: If Reinier has a better solution, I think a better solution beats any rush to JDK 8 with a lesser solution. If there is JVM code already written, I can understand the hesitancy to change things midstream. However, right now I am only aware of a well-written PDF. Alex, are you saying that refinements are no longer wanted at this point-in-time? Paul On Wed, Nov 28, 2012 at 8:13 AM, Reinier Zwitserloot < reinier at zwitserloot.com> wrote: > Okay, so you're going on record that it's official policy to knowingly run > with a clearly half-baked proposal, closing the door on any further review > a scant 3 months after posting a specification (which had already been > mostly implemented at that point according to the first post on this list). > > Not just that, there isn't even an explanation for why this feature is so > incredibly important that it must be released right now, half-baked. This > feature seems like the opposite: It enables nothing that can't already be > done with JDK7. It feels like a coin improvement: Nice syntax sugar but > that's it. > > _THIS_ is getting rushed? > > That's surprising, and I cannot find words to express how incredibly > disappointed I am. Combining java's dedication to backwards compatibility > with rushed ill-considered specs for no clearly stated reason... do I > really need to explain how that sounds like a truly horrible plan? > > There is a very serious cost associated with carrying on with this proposal > oblivious to the issues that surround it: There are ways to do this right, > but by pushing ahead now, you're closing the door on these forever. It's > java.util.Date + java.util.Calendar, except at the JLS level. > > Please, pretty please, with sugar on top, reconsider. > From r.spilker at gmail.com Wed Nov 28 07:50:19 2012 From: r.spilker at gmail.com (Roel Spilker) Date: Wed, 28 Nov 2012 16:50:19 +0100 Subject: Some smallish comments on the current version of the spec. In-Reply-To: References: <50B4083A.9060208@oracle.com> <50B53489.3020703@oracle.com> <50B54F9E.8050303@oracle.com> Message-ID: Hi Paul, others, The proposed solution by Reinier is not (yet) written down as a spec, let alone a nice PDF. Reinier and I see an alternative solution that has many (if not all) of the benefits of this solution but none of the downsides. Before making this into a spec we wanted to get some feedback on the ideas behind our proposal. In short: @Repeatable @interface Foo { } would be the way to make an annotation repeatable. @interface Repeatable { // Specify for which targets the annotation might be repeated Target[] value() default {}; } All annotations would be stored in the class file as they are in the source file. For backward compatibility reasons, it is also possible to use container annotations. @interface Foos { @Container Foo[] value(); } By annotating the annotation method instead of the Foos type, it is possible to lift the restriction that is can only be used for existing annotation containers that use the "value" method. Also, since it is on an annotation method, there is no need to specify the type of the contained elements; it is the return type of the method. If at runtime the user asks for the annotations on an element by getAnnotation(Foos.class), and there is none, and the Foos.class is marked as a container annotation, and there are Foo annotations present, a Foos instance is created. This is quite similar to the current process, except it happens at runtime instead of at compiletime. Lots of work from the current proposal regarding compatibility and spec, for instance the rule that container annotations can not have other methods unless they have a default value, can be reused in this proposal. Even shorter: - Store the annotations in the class file as they are in the source file - Backwards compatibility can be done at runtime That means that new APIs don't need to create container annotations that should not be used by their users but are publicly visible anyway. And old APIs can mark their container annotations as @Deprecated and drop/remove them as they please. Roel On Wed, Nov 28, 2012 at 3:56 PM, Paul Benedict wrote: > If Reinier has a better solution, I think a better solution beats any rush > to JDK 8 with a lesser solution. If there is JVM code already written, I > can understand the hesitancy to change things midstream. However, right now > I am only aware of a well-written PDF. > > Alex, are you saying that refinements are no longer wanted at this > point-in-time? > > Paul > > On Wed, Nov 28, 2012 at 8:13 AM, Reinier Zwitserloot < > reinier at zwitserloot.com> wrote: > > > Okay, so you're going on record that it's official policy to knowingly > run > > with a clearly half-baked proposal, closing the door on any further > review > > a scant 3 months after posting a specification (which had already been > > mostly implemented at that point according to the first post on this > list). > > > > Not just that, there isn't even an explanation for why this feature is so > > incredibly important that it must be released right now, half-baked. This > > feature seems like the opposite: It enables nothing that can't already be > > done with JDK7. It feels like a coin improvement: Nice syntax sugar but > > that's it. > > > > _THIS_ is getting rushed? > > > > That's surprising, and I cannot find words to express how incredibly > > disappointed I am. Combining java's dedication to backwards compatibility > > with rushed ill-considered specs for no clearly stated reason... do I > > really need to explain how that sounds like a truly horrible plan? > > > > There is a very serious cost associated with carrying on with this > proposal > > oblivious to the issues that surround it: There are ways to do this > right, > > but by pushing ahead now, you're closing the door on these forever. It's > > java.util.Date + java.util.Calendar, except at the JLS level. > > > > Please, pretty please, with sugar on top, reconsider. > > > From r.spilker at gmail.com Wed Nov 28 08:33:41 2012 From: r.spilker at gmail.com (Roel Spilker) Date: Wed, 28 Nov 2012 17:33:41 +0100 Subject: Rename @ContainedBy to @Repeatable Message-ID: I don't think that the annotation @ContainedBy reflects the fact that the main purpose of the annotation is to modify the cardinality for the user. That some compiler magic moves it to a container annotation is for the library users irrelevant. Roel From forax at univ-mlv.fr Wed Nov 28 10:49:44 2012 From: forax at univ-mlv.fr (Remi Forax) Date: Wed, 28 Nov 2012 19:49:44 +0100 Subject: Some smallish comments on the current version of the spec. In-Reply-To: References: <50B4083A.9060208@oracle.com> <50B53489.3020703@oracle.com> <50B54F9E.8050303@oracle.com> Message-ID: <50B65CC8.5010403@univ-mlv.fr> Reiner, Roel, I don't really like the current spec but it's not clear to me that your proposals are better or even realistic. Given that the code that deals with repeatable annotations is now available. http://hg.openjdk.java.net/jdk8/tl/jdk/rev/735b93462eed and that obviously you have cycles to spend on that, so please not only propose a spec but also a patch (using the tl workspace) and show us that too late for Oracle doesn't not always implies too late for Java. R?mi On 11/28/2012 04:50 PM, Roel Spilker wrote: > Hi Paul, others, > > The proposed solution by Reinier is not (yet) written down as a spec, let > alone a nice PDF. Reinier and I see an alternative solution that has many > (if not all) of the benefits of this solution but none of the downsides. > Before making this into a spec we wanted to get some feedback on the ideas > behind our proposal. > > In short: > > @Repeatable > @interface Foo { > } > > would be the way to make an annotation repeatable. > > @interface Repeatable { > // Specify for which targets the annotation might be repeated > Target[] value() default {}; > } > > > All annotations would be stored in the class file as they are in the source > file. > > For backward compatibility reasons, it is also possible to use container > annotations. > > @interface Foos { > @Container > Foo[] value(); > } > > By annotating the annotation method instead of the Foos type, it is > possible to lift the restriction that is can only be used for existing > annotation containers that use the "value" method. Also, since it is on an > annotation method, there is no need to specify the type of the contained > elements; it is the return type of the method. > > If at runtime the user asks for the annotations on an element by > getAnnotation(Foos.class), and there is none, and the Foos.class is marked > as a container annotation, and there are Foo annotations present, a Foos > instance is created. This is quite similar to the current process, except > it happens at runtime instead of at compiletime. > > Lots of work from the current proposal regarding compatibility and spec, > for instance the rule that container annotations can not have other methods > unless they have a default value, can be reused in this proposal. > > Even shorter: > - Store the annotations in the class file as they are in the source file > - Backwards compatibility can be done at runtime > > That means that new APIs don't need to create container annotations that > should not be used by their users but are publicly visible anyway. And old > APIs can mark their container annotations as @Deprecated and drop/remove > them as they please. > > Roel > > > > > On Wed, Nov 28, 2012 at 3:56 PM, Paul Benedict wrote: > >> If Reinier has a better solution, I think a better solution beats any rush >> to JDK 8 with a lesser solution. If there is JVM code already written, I >> can understand the hesitancy to change things midstream. However, right now >> I am only aware of a well-written PDF. >> >> Alex, are you saying that refinements are no longer wanted at this >> point-in-time? >> >> Paul >> >> On Wed, Nov 28, 2012 at 8:13 AM, Reinier Zwitserloot < >> reinier at zwitserloot.com> wrote: >> >>> Okay, so you're going on record that it's official policy to knowingly >> run >>> with a clearly half-baked proposal, closing the door on any further >> review >>> a scant 3 months after posting a specification (which had already been >>> mostly implemented at that point according to the first post on this >> list). >>> Not just that, there isn't even an explanation for why this feature is so >>> incredibly important that it must be released right now, half-baked. This >>> feature seems like the opposite: It enables nothing that can't already be >>> done with JDK7. It feels like a coin improvement: Nice syntax sugar but >>> that's it. >>> >>> _THIS_ is getting rushed? >>> >>> That's surprising, and I cannot find words to express how incredibly >>> disappointed I am. Combining java's dedication to backwards compatibility >>> with rushed ill-considered specs for no clearly stated reason... do I >>> really need to explain how that sounds like a truly horrible plan? >>> >>> There is a very serious cost associated with carrying on with this >> proposal >>> oblivious to the issues that surround it: There are ways to do this >> right, >>> but by pushing ahead now, you're closing the door on these forever. It's >>> java.util.Date + java.util.Calendar, except at the JLS level. >>> >>> Please, pretty please, with sugar on top, reconsider. >>> From joe.darcy at oracle.com Wed Nov 28 11:22:05 2012 From: joe.darcy at oracle.com (Joe Darcy) Date: Wed, 28 Nov 2012 11:22:05 -0800 Subject: Some smallish comments on the current version of the spec. In-Reply-To: <50B65CC8.5010403@univ-mlv.fr> References: <50B4083A.9060208@oracle.com> <50B53489.3020703@oracle.com> <50B54F9E.8050303@oracle.com> <50B65CC8.5010403@univ-mlv.fr> Message-ID: <50B6645D.2010206@oracle.com> On 11/28/2012 10:49 AM, Remi Forax wrote: > Reiner, Roel, > I don't really like the current spec but it's not clear to me that > your proposals are better or even realistic. > > Given that the code that deals with repeatable annotations is now > available. > http://hg.openjdk.java.net/jdk8/tl/jdk/rev/735b93462eed > and that obviously you have cycles to spend on that, Note that javac support for repeating annotations (7151010 Add compiler support for repeating annotations) has available in promoted builds of JDK 8 since b56, which shipped in September. -Joe > so please not only propose a spec but also a patch (using the tl > workspace) and > show us that too late for Oracle doesn't not always implies too late > for Java. > > R?mi > > On 11/28/2012 04:50 PM, Roel Spilker wrote: >> Hi Paul, others, >> >> The proposed solution by Reinier is not (yet) written down as a spec, >> let >> alone a nice PDF. Reinier and I see an alternative solution that has >> many >> (if not all) of the benefits of this solution but none of the downsides. >> Before making this into a spec we wanted to get some feedback on the >> ideas >> behind our proposal. >> >> In short: >> >> @Repeatable >> @interface Foo { >> } >> >> would be the way to make an annotation repeatable. >> >> @interface Repeatable { >> // Specify for which targets the annotation might be repeated >> Target[] value() default {}; >> } >> >> >> All annotations would be stored in the class file as they are in the >> source >> file. >> >> For backward compatibility reasons, it is also possible to use container >> annotations. >> >> @interface Foos { >> @Container >> Foo[] value(); >> } >> >> By annotating the annotation method instead of the Foos type, it is >> possible to lift the restriction that is can only be used for existing >> annotation containers that use the "value" method. Also, since it is >> on an >> annotation method, there is no need to specify the type of the contained >> elements; it is the return type of the method. >> >> If at runtime the user asks for the annotations on an element by >> getAnnotation(Foos.class), and there is none, and the Foos.class is >> marked >> as a container annotation, and there are Foo annotations present, a Foos >> instance is created. This is quite similar to the current process, >> except >> it happens at runtime instead of at compiletime. >> >> Lots of work from the current proposal regarding compatibility and spec, >> for instance the rule that container annotations can not have other >> methods >> unless they have a default value, can be reused in this proposal. >> >> Even shorter: >> - Store the annotations in the class file as they are in the source file >> - Backwards compatibility can be done at runtime >> >> That means that new APIs don't need to create container annotations that >> should not be used by their users but are publicly visible anyway. >> And old >> APIs can mark their container annotations as @Deprecated and drop/remove >> them as they please. >> >> Roel >> >> >> >> >> On Wed, Nov 28, 2012 at 3:56 PM, Paul Benedict >> wrote: >> >>> If Reinier has a better solution, I think a better solution beats >>> any rush >>> to JDK 8 with a lesser solution. If there is JVM code already >>> written, I >>> can understand the hesitancy to change things midstream. However, >>> right now >>> I am only aware of a well-written PDF. >>> >>> Alex, are you saying that refinements are no longer wanted at this >>> point-in-time? >>> >>> Paul >>> >>> On Wed, Nov 28, 2012 at 8:13 AM, Reinier Zwitserloot < >>> reinier at zwitserloot.com> wrote: >>> >>>> Okay, so you're going on record that it's official policy to knowingly >>> run >>>> with a clearly half-baked proposal, closing the door on any further >>> review >>>> a scant 3 months after posting a specification (which had already been >>>> mostly implemented at that point according to the first post on this >>> list). >>>> Not just that, there isn't even an explanation for why this feature >>>> is so >>>> incredibly important that it must be released right now, >>>> half-baked. This >>>> feature seems like the opposite: It enables nothing that can't >>>> already be >>>> done with JDK7. It feels like a coin improvement: Nice syntax sugar >>>> but >>>> that's it. >>>> >>>> _THIS_ is getting rushed? >>>> >>>> That's surprising, and I cannot find words to express how incredibly >>>> disappointed I am. Combining java's dedication to backwards >>>> compatibility >>>> with rushed ill-considered specs for no clearly stated reason... do I >>>> really need to explain how that sounds like a truly horrible plan? >>>> >>>> There is a very serious cost associated with carrying on with this >>> proposal >>>> oblivious to the issues that surround it: There are ways to do this >>> right, >>>> but by pushing ahead now, you're closing the door on these forever. >>>> It's >>>> java.util.Date + java.util.Calendar, except at the JLS level. >>>> >>>> Please, pretty please, with sugar on top, reconsider. >>>> > From alex.buckley at oracle.com Wed Nov 28 11:27:50 2012 From: alex.buckley at oracle.com (Alex Buckley) Date: Wed, 28 Nov 2012 11:27:50 -0800 Subject: Some smallish comments on the current version of the spec. In-Reply-To: References: <50B4083A.9060208@oracle.com> <50B53489.3020703@oracle.com> <50B54F9E.8050303@oracle.com> Message-ID: <50B665B6.5070705@oracle.com> On 11/28/2012 6:13 AM, Reinier Zwitserloot wrote: > Okay, so you're going on record that it's official policy to knowingly > run with a clearly half-baked proposal, closing the door on any further > review a scant 3 months after posting a specification (which had already > been mostly implemented at that point according to the first post on > this list). I said nothing of the sort and will not respond to you further. Alex From alex.buckley at oracle.com Wed Nov 28 11:30:40 2012 From: alex.buckley at oracle.com (Alex Buckley) Date: Wed, 28 Nov 2012 11:30:40 -0800 Subject: Some smallish comments on the current version of the spec. In-Reply-To: References: <50B4083A.9060208@oracle.com> <50B53489.3020703@oracle.com> <50B54F9E.8050303@oracle.com> Message-ID: <50B66660.3090204@oracle.com> Roel, November 2012 is not the time to sketch out a design for this feature. Please note: - JEP 120 "Repeating Annotations" [1] was posted in October 2011. Its revision history is public [2]. - I proposed a list to discuss the design and specification of the feature in July 2012 [3]. - I announced the creation of this mailing list in August 2012 [4] and immediately published a draft specification to it [5]. - Work has proceeded on both the specification (here) and the reference implementation (compiler-dev) since August 2012. The time for public comment on the design of the feature has passed. Alex [1] http://openjdk.java.net/jeps/120 [2] http://hg.openjdk.java.net/jep/jeps/log/tip/jep-120.md [3] http://mail.openjdk.java.net/pipermail/compiler-dev/2012-July/004548.html [4] http://mail.openjdk.java.net/pipermail/announce/2012-August/000132.html [5] http://mail.openjdk.java.net/pipermail/enhanced-metadata-spec-discuss/2012-August/000000.html On 11/28/2012 7:50 AM, Roel Spilker wrote: > Hi Paul, others, > > The proposed solution by Reinier is not (yet) written down as a spec, let > alone a nice PDF. Reinier and I see an alternative solution that has many > (if not all) of the benefits of this solution but none of the downsides. > Before making this into a spec we wanted to get some feedback on the ideas > behind our proposal. > > In short: > > @Repeatable > @interface Foo { > } > > would be the way to make an annotation repeatable. > > @interface Repeatable { > // Specify for which targets the annotation might be repeated > Target[] value() default {}; > } > > > All annotations would be stored in the class file as they are in the source > file. > > For backward compatibility reasons, it is also possible to use container > annotations. > > @interface Foos { > @Container > Foo[] value(); > } > > By annotating the annotation method instead of the Foos type, it is > possible to lift the restriction that is can only be used for existing > annotation containers that use the "value" method. Also, since it is on an > annotation method, there is no need to specify the type of the contained > elements; it is the return type of the method. > > If at runtime the user asks for the annotations on an element by > getAnnotation(Foos.class), and there is none, and the Foos.class is marked > as a container annotation, and there are Foo annotations present, a Foos > instance is created. This is quite similar to the current process, except > it happens at runtime instead of at compiletime. > > Lots of work from the current proposal regarding compatibility and spec, > for instance the rule that container annotations can not have other methods > unless they have a default value, can be reused in this proposal. > > Even shorter: > - Store the annotations in the class file as they are in the source file > - Backwards compatibility can be done at runtime > > That means that new APIs don't need to create container annotations that > should not be used by their users but are publicly visible anyway. And old > APIs can mark their container annotations as @Deprecated and drop/remove > them as they please. > > Roel > > > > > On Wed, Nov 28, 2012 at 3:56 PM, Paul Benedict wrote: > >> If Reinier has a better solution, I think a better solution beats any rush >> to JDK 8 with a lesser solution. If there is JVM code already written, I >> can understand the hesitancy to change things midstream. However, right now >> I am only aware of a well-written PDF. >> >> Alex, are you saying that refinements are no longer wanted at this >> point-in-time? >> >> Paul >> >> On Wed, Nov 28, 2012 at 8:13 AM, Reinier Zwitserloot < >> reinier at zwitserloot.com> wrote: >> >>> Okay, so you're going on record that it's official policy to knowingly >> run >>> with a clearly half-baked proposal, closing the door on any further >> review >>> a scant 3 months after posting a specification (which had already been >>> mostly implemented at that point according to the first post on this >> list). >>> >>> Not just that, there isn't even an explanation for why this feature is so >>> incredibly important that it must be released right now, half-baked. This >>> feature seems like the opposite: It enables nothing that can't already be >>> done with JDK7. It feels like a coin improvement: Nice syntax sugar but >>> that's it. >>> >>> _THIS_ is getting rushed? >>> >>> That's surprising, and I cannot find words to express how incredibly >>> disappointed I am. Combining java's dedication to backwards compatibility >>> with rushed ill-considered specs for no clearly stated reason... do I >>> really need to explain how that sounds like a truly horrible plan? >>> >>> There is a very serious cost associated with carrying on with this >> proposal >>> oblivious to the issues that surround it: There are ways to do this >> right, >>> but by pushing ahead now, you're closing the door on these forever. It's >>> java.util.Date + java.util.Calendar, except at the JLS level. >>> >>> Please, pretty please, with sugar on top, reconsider. >>> >> From alex.buckley at oracle.com Wed Nov 28 11:36:11 2012 From: alex.buckley at oracle.com (Alex Buckley) Date: Wed, 28 Nov 2012 11:36:11 -0800 Subject: JSR for Repeating Annotations language change In-Reply-To: References: Message-ID: <50B667AB.4060905@oracle.com> On 11/28/2012 6:13 AM, Roel Spilker wrote: > Can you tell me what JSR covers the language change regarding repeating > annotations? I looked at the list of JSRs at http://jcp.org/en/jsr/all but > could not identify the right JSR based on their descriptions. JSR 337. I carefully explained where and how the Repeating Annotations feature would be discussed when I proposed this mailing list [1] and when I announced its creation to the OpenJDK community [2][3]. Alex [1] http://mail.openjdk.java.net/pipermail/compiler-dev/2012-July/004548.html [2] http://mail.openjdk.java.net/pipermail/compiler-dev/2012-August/004636.html [3] http://mail.openjdk.java.net/pipermail/announce/2012-August/000132.html From r.spilker at gmail.com Wed Nov 28 15:31:17 2012 From: r.spilker at gmail.com (Roel Spilker) Date: Thu, 29 Nov 2012 00:31:17 +0100 Subject: Some smallish comments on the current version of the spec. In-Reply-To: <50B65CC8.5010403@univ-mlv.fr> References: <50B4083A.9060208@oracle.com> <50B53489.3020703@oracle.com> <50B54F9E.8050303@oracle.com> <50B65CC8.5010403@univ-mlv.fr> Message-ID: Hi Remi, What I can probably do in relative short time is write an implementation that makes Javac put all the repeated annotations in the classfile directly (without a container) and make the reflection API work as we proposed. I can also rewrite the JLS document to reflect those changes. Generating the right error messages might come later. If all goes well, I will make it easily possible to test this in a live environment. Before spending more time on it, I like to get some feedback indicating more work will be appreciated. Would that be useful? Or will any time I invest on this be wasted? Roel On Wed, Nov 28, 2012 at 7:49 PM, Remi Forax wrote: > Reiner, Roel, > I don't really like the current spec but it's not clear to me that your > proposals are better or even realistic. > > Given that the code that deals with repeatable annotations is now > available. > http://hg.openjdk.java.net/**jdk8/tl/jdk/rev/735b93462eed > and that obviously you have cycles to spend on that, > so please not only propose a spec but also a patch (using the tl > workspace) and > show us that too late for Oracle doesn't not always implies too late for > Java. > > R?mi > > > On 11/28/2012 04:50 PM, Roel Spilker wrote: > >> Hi Paul, others, >> >> The proposed solution by Reinier is not (yet) written down as a spec, let >> alone a nice PDF. Reinier and I see an alternative solution that has many >> (if not all) of the benefits of this solution but none of the downsides. >> Before making this into a spec we wanted to get some feedback on the ideas >> behind our proposal. >> >> In short: >> >> @Repeatable >> @interface Foo { >> } >> >> would be the way to make an annotation repeatable. >> >> @interface Repeatable { >> // Specify for which targets the annotation might be repeated >> Target[] value() default {}; >> } >> >> >> All annotations would be stored in the class file as they are in the >> source >> file. >> >> For backward compatibility reasons, it is also possible to use container >> annotations. >> >> @interface Foos { >> @Container >> Foo[] value(); >> } >> >> By annotating the annotation method instead of the Foos type, it is >> possible to lift the restriction that is can only be used for existing >> annotation containers that use the "value" method. Also, since it is on an >> annotation method, there is no need to specify the type of the contained >> elements; it is the return type of the method. >> >> If at runtime the user asks for the annotations on an element by >> getAnnotation(Foos.class), and there is none, and the Foos.class is marked >> as a container annotation, and there are Foo annotations present, a Foos >> instance is created. This is quite similar to the current process, except >> it happens at runtime instead of at compiletime. >> >> Lots of work from the current proposal regarding compatibility and spec, >> for instance the rule that container annotations can not have other >> methods >> unless they have a default value, can be reused in this proposal. >> >> Even shorter: >> - Store the annotations in the class file as they are in the source file >> - Backwards compatibility can be done at runtime >> >> That means that new APIs don't need to create container annotations that >> should not be used by their users but are publicly visible anyway. And old >> APIs can mark their container annotations as @Deprecated and drop/remove >> them as they please. >> >> Roel >> >> >> >> >> On Wed, Nov 28, 2012 at 3:56 PM, Paul Benedict >> wrote: >> >> If Reinier has a better solution, I think a better solution beats any >>> rush >>> to JDK 8 with a lesser solution. If there is JVM code already written, I >>> can understand the hesitancy to change things midstream. However, right >>> now >>> I am only aware of a well-written PDF. >>> >>> Alex, are you saying that refinements are no longer wanted at this >>> point-in-time? >>> >>> Paul >>> >>> On Wed, Nov 28, 2012 at 8:13 AM, Reinier Zwitserloot < >>> reinier at zwitserloot.com> wrote: >>> >>> Okay, so you're going on record that it's official policy to knowingly >>>> >>> run >>> >>>> with a clearly half-baked proposal, closing the door on any further >>>> >>> review >>> >>>> a scant 3 months after posting a specification (which had already been >>>> mostly implemented at that point according to the first post on this >>>> >>> list). >>> >>>> Not just that, there isn't even an explanation for why this feature is >>>> so >>>> incredibly important that it must be released right now, half-baked. >>>> This >>>> feature seems like the opposite: It enables nothing that can't already >>>> be >>>> done with JDK7. It feels like a coin improvement: Nice syntax sugar but >>>> that's it. >>>> >>>> _THIS_ is getting rushed? >>>> >>>> That's surprising, and I cannot find words to express how incredibly >>>> disappointed I am. Combining java's dedication to backwards >>>> compatibility >>>> with rushed ill-considered specs for no clearly stated reason... do I >>>> really need to explain how that sounds like a truly horrible plan? >>>> >>>> There is a very serious cost associated with carrying on with this >>>> >>> proposal >>> >>>> oblivious to the issues that surround it: There are ways to do this >>>> >>> right, >>> >>>> but by pushing ahead now, you're closing the door on these forever. It's >>>> java.util.Date + java.util.Calendar, except at the JLS level. >>>> >>>> Please, pretty please, with sugar on top, reconsider. >>>> >>>> > From alex.buckley at oracle.com Wed Nov 28 16:22:32 2012 From: alex.buckley at oracle.com (Alex Buckley) Date: Wed, 28 Nov 2012 16:22:32 -0800 Subject: Some smallish comments on the current version of the spec. In-Reply-To: References: <50B4083A.9060208@oracle.com> <50B53489.3020703@oracle.com> <50B54F9E.8050303@oracle.com> <50B65CC8.5010403@univ-mlv.fr> Message-ID: <50B6AAC8.4060007@oracle.com> Roel, First of all, your name doesn't appear in the OpenJDK Census (http://openjdk.java.net/census). You would need to sign the OCA to become a Contributor before sending any code to compiler-dev for review. See the OpenJDK web site for more details. Second, the design of Repeating Annotations is not going to change after having been public for 13 months. An implementation of an alternative design will not be accepted by any Committer on the JDK8 project. Please move on. Alex On 11/28/2012 3:31 PM, Roel Spilker wrote: > Hi Remi, > > What I can probably do in relative short time is write an implementation > that makes Javac put all the repeated annotations in the classfile directly > (without a container) and make the reflection API work as we proposed. I > can also rewrite the JLS document to reflect those changes. Generating the > right error messages might come later. > > If all goes well, I will make it easily possible to test this in a live > environment. Before spending more time on it, I like to get some feedback > indicating more work will be appreciated. > > Would that be useful? Or will any time I invest on this be wasted? > > Roel > > > > On Wed, Nov 28, 2012 at 7:49 PM, Remi Forax wrote: > >> Reiner, Roel, >> I don't really like the current spec but it's not clear to me that your >> proposals are better or even realistic. >> >> Given that the code that deals with repeatable annotations is now >> available. >> http://hg.openjdk.java.net/**jdk8/tl/jdk/rev/735b93462eed >> and that obviously you have cycles to spend on that, >> so please not only propose a spec but also a patch (using the tl >> workspace) and >> show us that too late for Oracle doesn't not always implies too late for >> Java. >> >> R?mi >> >> >> On 11/28/2012 04:50 PM, Roel Spilker wrote: >> >>> Hi Paul, others, >>> >>> The proposed solution by Reinier is not (yet) written down as a spec, let >>> alone a nice PDF. Reinier and I see an alternative solution that has many >>> (if not all) of the benefits of this solution but none of the downsides. >>> Before making this into a spec we wanted to get some feedback on the ideas >>> behind our proposal. >>> >>> In short: >>> >>> @Repeatable >>> @interface Foo { >>> } >>> >>> would be the way to make an annotation repeatable. >>> >>> @interface Repeatable { >>> // Specify for which targets the annotation might be repeated >>> Target[] value() default {}; >>> } >>> >>> >>> All annotations would be stored in the class file as they are in the >>> source >>> file. >>> >>> For backward compatibility reasons, it is also possible to use container >>> annotations. >>> >>> @interface Foos { >>> @Container >>> Foo[] value(); >>> } >>> >>> By annotating the annotation method instead of the Foos type, it is >>> possible to lift the restriction that is can only be used for existing >>> annotation containers that use the "value" method. Also, since it is on an >>> annotation method, there is no need to specify the type of the contained >>> elements; it is the return type of the method. >>> >>> If at runtime the user asks for the annotations on an element by >>> getAnnotation(Foos.class), and there is none, and the Foos.class is marked >>> as a container annotation, and there are Foo annotations present, a Foos >>> instance is created. This is quite similar to the current process, except >>> it happens at runtime instead of at compiletime. >>> >>> Lots of work from the current proposal regarding compatibility and spec, >>> for instance the rule that container annotations can not have other >>> methods >>> unless they have a default value, can be reused in this proposal. >>> >>> Even shorter: >>> - Store the annotations in the class file as they are in the source file >>> - Backwards compatibility can be done at runtime >>> >>> That means that new APIs don't need to create container annotations that >>> should not be used by their users but are publicly visible anyway. And old >>> APIs can mark their container annotations as @Deprecated and drop/remove >>> them as they please. >>> >>> Roel >>> >>> >>> >>> >>> On Wed, Nov 28, 2012 at 3:56 PM, Paul Benedict >>> wrote: >>> >>> If Reinier has a better solution, I think a better solution beats any >>>> rush >>>> to JDK 8 with a lesser solution. If there is JVM code already written, I >>>> can understand the hesitancy to change things midstream. However, right >>>> now >>>> I am only aware of a well-written PDF. >>>> >>>> Alex, are you saying that refinements are no longer wanted at this >>>> point-in-time? >>>> >>>> Paul >>>> >>>> On Wed, Nov 28, 2012 at 8:13 AM, Reinier Zwitserloot < >>>> reinier at zwitserloot.com> wrote: >>>> >>>> Okay, so you're going on record that it's official policy to knowingly >>>>> >>>> run >>>> >>>>> with a clearly half-baked proposal, closing the door on any further >>>>> >>>> review >>>> >>>>> a scant 3 months after posting a specification (which had already been >>>>> mostly implemented at that point according to the first post on this >>>>> >>>> list). >>>> >>>>> Not just that, there isn't even an explanation for why this feature is >>>>> so >>>>> incredibly important that it must be released right now, half-baked. >>>>> This >>>>> feature seems like the opposite: It enables nothing that can't already >>>>> be >>>>> done with JDK7. It feels like a coin improvement: Nice syntax sugar but >>>>> that's it. >>>>> >>>>> _THIS_ is getting rushed? >>>>> >>>>> That's surprising, and I cannot find words to express how incredibly >>>>> disappointed I am. Combining java's dedication to backwards >>>>> compatibility >>>>> with rushed ill-considered specs for no clearly stated reason... do I >>>>> really need to explain how that sounds like a truly horrible plan? >>>>> >>>>> There is a very serious cost associated with carrying on with this >>>>> >>>> proposal >>>> >>>>> oblivious to the issues that surround it: There are ways to do this >>>>> >>>> right, >>>> >>>>> but by pushing ahead now, you're closing the door on these forever. It's >>>>> java.util.Date + java.util.Calendar, except at the JLS level. >>>>> >>>>> Please, pretty please, with sugar on top, reconsider. >>>>> >>>>> >> From scolebourne at joda.org Wed Nov 28 16:38:05 2012 From: scolebourne at joda.org (Stephen Colebourne) Date: Thu, 29 Nov 2012 00:38:05 +0000 Subject: Some smallish comments on the current version of the spec. In-Reply-To: <50B6AAC8.4060007@oracle.com> References: <50B4083A.9060208@oracle.com> <50B53489.3020703@oracle.com> <50B54F9E.8050303@oracle.com> <50B65CC8.5010403@univ-mlv.fr> <50B6AAC8.4060007@oracle.com> Message-ID: On 29 November 2012 00:22, Alex Buckley wrote: > First of all, your name doesn't appear in the OpenJDK Census > (http://openjdk.java.net/census). You would need to sign the OCA to become a > Contributor before sending any code to compiler-dev for review. See the > OpenJDK web site for more details. > > Second, the design of Repeating Annotations is not going to change after > having been public for 13 months. An implementation of an alternative design > will not be accepted by any Committer on the JDK8 project. Please move on. I would note that the specification of Java SE 8 is, according to the rules, defined by the JCP, not OpenJDK or Oracle. Roel/Reinier do have the option of trying to persuade the JCP EC to reject the feature as currently written. Of course, since this would also involve rejecting the rest of Java SE 8 it is highly unlikely to happen. The phrase Rubber Stamp does come to mind at this point... More generally, I think there is merit in both positions in this thread. Oracle have the right to say times up, and the community has the right to say they think Oracle have got it wrong. However, since Oracle has already invested in this, has performed reasonable public scrutiny, and ultimately has all the power, the reality is that this discussion is moot. Stephen (no reply required) From forax at univ-mlv.fr Wed Nov 28 16:44:54 2012 From: forax at univ-mlv.fr (Remi Forax) Date: Thu, 29 Nov 2012 01:44:54 +0100 Subject: Some smallish comments on the current version of the spec. In-Reply-To: <50B6AAC8.4060007@oracle.com> References: <50B4083A.9060208@oracle.com> <50B53489.3020703@oracle.com> <50B54F9E.8050303@oracle.com> <50B65CC8.5010403@univ-mlv.fr> <50B6AAC8.4060007@oracle.com> Message-ID: <50B6B006.6060501@univ-mlv.fr> Hi Alex, the good news is that someone want to contribute to the OpenJDK, don't forget that there is always a bright side :) and the no so good news is that instead of fixing some bugs in java.something, he has decided to fix something already discussed and polished by Oracle. I know that you are risk averse but there is only a small risk to let someone to provide his specification and his implementation given that the Oracle implementation is already ready, you may waste time. But the benefit can be high, if the proposal and its implementation is better technically that the one proposed by Oracle it means that Oracle may be able to outsource some part of his development, so it's a small bet on the future of OpenJDK. Practically, I propose that you should indicate a reasonable deadline to Roel, at that time it should provide a spec, an implementation of the compiler part and an implementation of the reflection part making clear that there is no promise about the fact that his proposal will be chosen or not. At that point, you can choose which implementation is better than the other. I will help you publicly on the mailing list if the proposal is not better than the Oracle one at least we will have tried to make people contribute. I know that you have invested a lot of your own time on the Oracle spec and that I ask you to also spend time to review the Roel's proposal, but please stop to say move on on people that want to contribute. R?mi On 11/29/2012 01:22 AM, Alex Buckley wrote: > Roel, > > First of all, your name doesn't appear in the OpenJDK Census > (http://openjdk.java.net/census). You would need to sign the OCA to > become a Contributor before sending any code to compiler-dev for > review. See the OpenJDK web site for more details. > > Second, the design of Repeating Annotations is not going to change > after having been public for 13 months. An implementation of an > alternative design will not be accepted by any Committer on the JDK8 > project. Please move on. > > Alex > > On 11/28/2012 3:31 PM, Roel Spilker wrote: >> Hi Remi, >> >> What I can probably do in relative short time is write an implementation >> that makes Javac put all the repeated annotations in the classfile >> directly >> (without a container) and make the reflection API work as we proposed. I >> can also rewrite the JLS document to reflect those changes. >> Generating the >> right error messages might come later. >> >> If all goes well, I will make it easily possible to test this in a live >> environment. Before spending more time on it, I like to get some >> feedback >> indicating more work will be appreciated. >> >> Would that be useful? Or will any time I invest on this be wasted? >> >> Roel >> >> >> >> On Wed, Nov 28, 2012 at 7:49 PM, Remi Forax wrote: >> >>> Reiner, Roel, >>> I don't really like the current spec but it's not clear to me that your >>> proposals are better or even realistic. >>> >>> Given that the code that deals with repeatable annotations is now >>> available. >>> http://hg.openjdk.java.net/**jdk8/tl/jdk/rev/735b93462eed >>> and that obviously you have cycles to spend on that, >>> so please not only propose a spec but also a patch (using the tl >>> workspace) and >>> show us that too late for Oracle doesn't not always implies too late >>> for >>> Java. >>> >>> R?mi >>> >>> >>> On 11/28/2012 04:50 PM, Roel Spilker wrote: >>> >>>> Hi Paul, others, >>>> >>>> The proposed solution by Reinier is not (yet) written down as a >>>> spec, let >>>> alone a nice PDF. Reinier and I see an alternative solution that >>>> has many >>>> (if not all) of the benefits of this solution but none of the >>>> downsides. >>>> Before making this into a spec we wanted to get some feedback on >>>> the ideas >>>> behind our proposal. >>>> >>>> In short: >>>> >>>> @Repeatable >>>> @interface Foo { >>>> } >>>> >>>> would be the way to make an annotation repeatable. >>>> >>>> @interface Repeatable { >>>> // Specify for which targets the annotation might be repeated >>>> Target[] value() default {}; >>>> } >>>> >>>> >>>> All annotations would be stored in the class file as they are in the >>>> source >>>> file. >>>> >>>> For backward compatibility reasons, it is also possible to use >>>> container >>>> annotations. >>>> >>>> @interface Foos { >>>> @Container >>>> Foo[] value(); >>>> } >>>> >>>> By annotating the annotation method instead of the Foos type, it is >>>> possible to lift the restriction that is can only be used for existing >>>> annotation containers that use the "value" method. Also, since it >>>> is on an >>>> annotation method, there is no need to specify the type of the >>>> contained >>>> elements; it is the return type of the method. >>>> >>>> If at runtime the user asks for the annotations on an element by >>>> getAnnotation(Foos.class), and there is none, and the Foos.class is >>>> marked >>>> as a container annotation, and there are Foo annotations present, a >>>> Foos >>>> instance is created. This is quite similar to the current process, >>>> except >>>> it happens at runtime instead of at compiletime. >>>> >>>> Lots of work from the current proposal regarding compatibility and >>>> spec, >>>> for instance the rule that container annotations can not have other >>>> methods >>>> unless they have a default value, can be reused in this proposal. >>>> >>>> Even shorter: >>>> - Store the annotations in the class file as they are in the source >>>> file >>>> - Backwards compatibility can be done at runtime >>>> >>>> That means that new APIs don't need to create container annotations >>>> that >>>> should not be used by their users but are publicly visible anyway. >>>> And old >>>> APIs can mark their container annotations as @Deprecated and >>>> drop/remove >>>> them as they please. >>>> >>>> Roel >>>> >>>> >>>> >>>> >>>> On Wed, Nov 28, 2012 at 3:56 PM, Paul Benedict >>>> wrote: >>>> >>>> If Reinier has a better solution, I think a better solution beats >>>> any >>>>> rush >>>>> to JDK 8 with a lesser solution. If there is JVM code already >>>>> written, I >>>>> can understand the hesitancy to change things midstream. However, >>>>> right >>>>> now >>>>> I am only aware of a well-written PDF. >>>>> >>>>> Alex, are you saying that refinements are no longer wanted at this >>>>> point-in-time? >>>>> >>>>> Paul >>>>> >>>>> On Wed, Nov 28, 2012 at 8:13 AM, Reinier Zwitserloot < >>>>> reinier at zwitserloot.com> wrote: >>>>> >>>>> Okay, so you're going on record that it's official policy to >>>>> knowingly >>>>>> >>>>> run >>>>> >>>>>> with a clearly half-baked proposal, closing the door on any further >>>>>> >>>>> review >>>>> >>>>>> a scant 3 months after posting a specification (which had already >>>>>> been >>>>>> mostly implemented at that point according to the first post on this >>>>>> >>>>> list). >>>>> >>>>>> Not just that, there isn't even an explanation for why this >>>>>> feature is >>>>>> so >>>>>> incredibly important that it must be released right now, half-baked. >>>>>> This >>>>>> feature seems like the opposite: It enables nothing that can't >>>>>> already >>>>>> be >>>>>> done with JDK7. It feels like a coin improvement: Nice syntax >>>>>> sugar but >>>>>> that's it. >>>>>> >>>>>> _THIS_ is getting rushed? >>>>>> >>>>>> That's surprising, and I cannot find words to express how incredibly >>>>>> disappointed I am. Combining java's dedication to backwards >>>>>> compatibility >>>>>> with rushed ill-considered specs for no clearly stated reason... >>>>>> do I >>>>>> really need to explain how that sounds like a truly horrible plan? >>>>>> >>>>>> There is a very serious cost associated with carrying on with this >>>>>> >>>>> proposal >>>>> >>>>>> oblivious to the issues that surround it: There are ways to do this >>>>>> >>>>> right, >>>>> >>>>>> but by pushing ahead now, you're closing the door on these >>>>>> forever. It's >>>>>> java.util.Date + java.util.Calendar, except at the JLS level. >>>>>> >>>>>> Please, pretty please, with sugar on top, reconsider. >>>>>> >>>>>> >>> From alex.buckley at oracle.com Wed Nov 28 17:08:02 2012 From: alex.buckley at oracle.com (Alex Buckley) Date: Wed, 28 Nov 2012 17:08:02 -0800 Subject: Some smallish comments on the current version of the spec. In-Reply-To: <50B6B006.6060501@univ-mlv.fr> References: <50B4083A.9060208@oracle.com> <50B53489.3020703@oracle.com> <50B54F9E.8050303@oracle.com> <50B65CC8.5010403@univ-mlv.fr> <50B6AAC8.4060007@oracle.com> <50B6B006.6060501@univ-mlv.fr> Message-ID: <50B6B572.3040208@oracle.com> This feature has been in the public plan for JDK8 since October 2011 and the vast majority of its implementation is in jdk8/tl today, ready for M6 in January 2013. If you've been following carefully, you would even have seen that repeating annotations are in the binary downloads for the Type Annotations project, so that both declaration and use-site annotations can repeat. It is too late for JDK8 to take an alternate design and implementation. This discussion is closed. Alex On 11/28/2012 4:44 PM, Remi Forax wrote: > Hi Alex, > the good news is that someone want to contribute to the OpenJDK, don't > forget that there is always a bright side :) and the no so good news is > that instead of fixing some bugs in java.something, he has decided to > fix something already discussed and polished by Oracle. > > I know that you are risk averse but there is only a small risk to let > someone to provide his specification and his implementation given that > the Oracle implementation is already ready, you may waste time. But the > benefit can be high, if the proposal and its implementation is better > technically that the one proposed by Oracle it means that Oracle may be > able to outsource some part of his development, so it's a small bet on > the future of OpenJDK. > > Practically, I propose that you should indicate a reasonable deadline to > Roel, at that time it should provide a spec, an implementation of the > compiler part and an implementation of the reflection part making clear > that there is no promise about the fact that his proposal will be chosen > or not. > At that point, you can choose which implementation is better than the > other. I will help you publicly on the mailing list if the proposal is > not better than the Oracle one at least we will have tried to make > people contribute. > > I know that you have invested a lot of your own time on the Oracle spec > and that I ask you to also spend time to review the Roel's proposal, but > please stop to say move on on people that want to contribute. > > R?mi > > On 11/29/2012 01:22 AM, Alex Buckley wrote: >> Roel, >> >> First of all, your name doesn't appear in the OpenJDK Census >> (http://openjdk.java.net/census). You would need to sign the OCA to >> become a Contributor before sending any code to compiler-dev for >> review. See the OpenJDK web site for more details. >> >> Second, the design of Repeating Annotations is not going to change >> after having been public for 13 months. An implementation of an >> alternative design will not be accepted by any Committer on the JDK8 >> project. Please move on. >> >> Alex >> >> On 11/28/2012 3:31 PM, Roel Spilker wrote: >>> Hi Remi, >>> >>> What I can probably do in relative short time is write an implementation >>> that makes Javac put all the repeated annotations in the classfile >>> directly >>> (without a container) and make the reflection API work as we proposed. I >>> can also rewrite the JLS document to reflect those changes. >>> Generating the >>> right error messages might come later. >>> >>> If all goes well, I will make it easily possible to test this in a live >>> environment. Before spending more time on it, I like to get some >>> feedback >>> indicating more work will be appreciated. >>> >>> Would that be useful? Or will any time I invest on this be wasted? >>> >>> Roel >>> >>> >>> >>> On Wed, Nov 28, 2012 at 7:49 PM, Remi Forax wrote: >>> >>>> Reiner, Roel, >>>> I don't really like the current spec but it's not clear to me that your >>>> proposals are better or even realistic. >>>> >>>> Given that the code that deals with repeatable annotations is now >>>> available. >>>> http://hg.openjdk.java.net/**jdk8/tl/jdk/rev/735b93462eed >>>> >>>> and that obviously you have cycles to spend on that, >>>> so please not only propose a spec but also a patch (using the tl >>>> workspace) and >>>> show us that too late for Oracle doesn't not always implies too late >>>> for >>>> Java. >>>> >>>> R?mi >>>> >>>> >>>> On 11/28/2012 04:50 PM, Roel Spilker wrote: >>>> >>>>> Hi Paul, others, >>>>> >>>>> The proposed solution by Reinier is not (yet) written down as a >>>>> spec, let >>>>> alone a nice PDF. Reinier and I see an alternative solution that >>>>> has many >>>>> (if not all) of the benefits of this solution but none of the >>>>> downsides. >>>>> Before making this into a spec we wanted to get some feedback on >>>>> the ideas >>>>> behind our proposal. >>>>> >>>>> In short: >>>>> >>>>> @Repeatable >>>>> @interface Foo { >>>>> } >>>>> >>>>> would be the way to make an annotation repeatable. >>>>> >>>>> @interface Repeatable { >>>>> // Specify for which targets the annotation might be repeated >>>>> Target[] value() default {}; >>>>> } >>>>> >>>>> >>>>> All annotations would be stored in the class file as they are in the >>>>> source >>>>> file. >>>>> >>>>> For backward compatibility reasons, it is also possible to use >>>>> container >>>>> annotations. >>>>> >>>>> @interface Foos { >>>>> @Container >>>>> Foo[] value(); >>>>> } >>>>> >>>>> By annotating the annotation method instead of the Foos type, it is >>>>> possible to lift the restriction that is can only be used for existing >>>>> annotation containers that use the "value" method. Also, since it >>>>> is on an >>>>> annotation method, there is no need to specify the type of the >>>>> contained >>>>> elements; it is the return type of the method. >>>>> >>>>> If at runtime the user asks for the annotations on an element by >>>>> getAnnotation(Foos.class), and there is none, and the Foos.class is >>>>> marked >>>>> as a container annotation, and there are Foo annotations present, a >>>>> Foos >>>>> instance is created. This is quite similar to the current process, >>>>> except >>>>> it happens at runtime instead of at compiletime. >>>>> >>>>> Lots of work from the current proposal regarding compatibility and >>>>> spec, >>>>> for instance the rule that container annotations can not have other >>>>> methods >>>>> unless they have a default value, can be reused in this proposal. >>>>> >>>>> Even shorter: >>>>> - Store the annotations in the class file as they are in the source >>>>> file >>>>> - Backwards compatibility can be done at runtime >>>>> >>>>> That means that new APIs don't need to create container annotations >>>>> that >>>>> should not be used by their users but are publicly visible anyway. >>>>> And old >>>>> APIs can mark their container annotations as @Deprecated and >>>>> drop/remove >>>>> them as they please. >>>>> >>>>> Roel >>>>> >>>>> >>>>> >>>>> >>>>> On Wed, Nov 28, 2012 at 3:56 PM, Paul Benedict >>>>> wrote: >>>>> >>>>> If Reinier has a better solution, I think a better solution beats >>>>> any >>>>>> rush >>>>>> to JDK 8 with a lesser solution. If there is JVM code already >>>>>> written, I >>>>>> can understand the hesitancy to change things midstream. However, >>>>>> right >>>>>> now >>>>>> I am only aware of a well-written PDF. >>>>>> >>>>>> Alex, are you saying that refinements are no longer wanted at this >>>>>> point-in-time? >>>>>> >>>>>> Paul >>>>>> >>>>>> On Wed, Nov 28, 2012 at 8:13 AM, Reinier Zwitserloot < >>>>>> reinier at zwitserloot.com> wrote: >>>>>> >>>>>> Okay, so you're going on record that it's official policy to >>>>>> knowingly >>>>>>> >>>>>> run >>>>>> >>>>>>> with a clearly half-baked proposal, closing the door on any further >>>>>>> >>>>>> review >>>>>> >>>>>>> a scant 3 months after posting a specification (which had already >>>>>>> been >>>>>>> mostly implemented at that point according to the first post on this >>>>>>> >>>>>> list). >>>>>> >>>>>>> Not just that, there isn't even an explanation for why this >>>>>>> feature is >>>>>>> so >>>>>>> incredibly important that it must be released right now, half-baked. >>>>>>> This >>>>>>> feature seems like the opposite: It enables nothing that can't >>>>>>> already >>>>>>> be >>>>>>> done with JDK7. It feels like a coin improvement: Nice syntax >>>>>>> sugar but >>>>>>> that's it. >>>>>>> >>>>>>> _THIS_ is getting rushed? >>>>>>> >>>>>>> That's surprising, and I cannot find words to express how incredibly >>>>>>> disappointed I am. Combining java's dedication to backwards >>>>>>> compatibility >>>>>>> with rushed ill-considered specs for no clearly stated reason... >>>>>>> do I >>>>>>> really need to explain how that sounds like a truly horrible plan? >>>>>>> >>>>>>> There is a very serious cost associated with carrying on with this >>>>>>> >>>>>> proposal >>>>>> >>>>>>> oblivious to the issues that surround it: There are ways to do this >>>>>>> >>>>>> right, >>>>>> >>>>>>> but by pushing ahead now, you're closing the door on these >>>>>>> forever. It's >>>>>>> java.util.Date + java.util.Calendar, except at the JLS level. >>>>>>> >>>>>>> Please, pretty please, with sugar on top, reconsider. >>>>>>> >>>>>>> >>>> > From r.spilker at gmail.com Thu Nov 29 08:11:58 2012 From: r.spilker at gmail.com (Roel Spilker) Date: Thu, 29 Nov 2012 17:11:58 +0100 Subject: Rename @ContainedBy to @Repeatable In-Reply-To: References: Message-ID: Based on the conversations on the other threads, I assume this is also too late. If my assumption is incorrect, I appreciate a response, otherwise consider this topic closed. Roel, moving on. On Wed, Nov 28, 2012 at 5:33 PM, Roel Spilker wrote: > I don't think that the annotation @ContainedBy reflects the fact that the > main purpose of the annotation is to modify the cardinality for the user. > That some compiler magic moves it to a container annotation is for the > library users irrelevant. > > Roel > >