Some smallish comments on the current version of the spec.

[Roel Spilker]

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