Some smallish comments on the current version of the spec.

[Remi Forax]

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 <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.
>>>