Some smallish comments on the current version of the spec.

[Alex Buckley]

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 <pbenedict at apache.org> 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.
>>>
>>