Some smallish comments on the current version of the spec.

Joe Darcy joe.darcy at
Wed Nov 28 11:22:05 PST 2012

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


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

More information about the enhanced-metadata-spec-discuss mailing list