Some smallish comments on the current version of the spec.

[Reinier Zwitserloot]

"@ContainerFor supports the java SE platform reflection…" - This paragraph
seems to make the point that it is important to differentiate
@FooContainer({@Foo(1), @Foo(2)}) from just @Foo(1) @Foo(2). Why is this
relevant? Also, later on, the examples of how JDK8 answers
.get(Declared)Annotation queries indicates that differentiating these two
cases in not actually important. That leaves the question of: Why is
@ContainerFor needed in the first place?

"@ContainerFor" itself: While the stated aim is to be as compatible with
existing containers as possible, there are now 2 restrictions:

* The container method must be "value()".
* All other methods must have a default.

There are also many DRY violations: There's both @ContainerFor and
@ContainedBy, _AND_ in the container annotation, the base type is repeated.
At the very least, it is possible to eliminate both the value() restriction
and one repetition of the base type by getting rid of @ContainerFor and
introducing the @Container marker annotation. This annotation goes on a
method in an annotation declaration and signals that this is the container
method, i.e. that the return type of this method must be A[], and it means
that the containing annotation is a container for A. There must be at most
1 @Container annotation, and all other methods must have a default.

In other words, instead of:

@ContainerFor(Foo.class) @interface FooContainer {
    Foo[] value();
}

We get:

@interface FooContainer {
    @Container Foo[] whatever();
}





 --Reinier Zwitserloot