Some smallish comments on the current version of the spec.

[Alex Buckley]

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 <forax at univ-mlv.fr> 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<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.
>>>>>>>
>>>>>>>
>>>>
>