Some smallish comments on the current version of the spec.

[Roel Spilker]

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