Spec update for repeatable/containing relationship

[Paul Benedict]

Alex,

Two questions on page 2...

(1) "An annotation type TC is the containing annotation type of T if all of
the following are true ... Any methods declared by TC other than value()
have a default value."

Shouldn't a compile error be emitted if this case fails? If I code a
container annotation but forget defaults on other methods, I think an error
should occur. I didn't see a line in the spec that explicitly stated this
behavior, but it would be helpful to developers.

(2) In regards to this paragraph: "@ContainerFor supports the Java SE
platform reflection API in differentiating automatically-generated
container annotations from legacy annotations which served as idiomatic
containers prior to Java SE 8."

I think this paragraph is incorrect regarding (a) automatically-generated
container annotations and (b) legacy annotations. For repeatability to
exist at all, a pairing of @ContainerFor and @ContainedBy annotation types
must exist at compile time. So this isn't about "legacy" code, and the
pairing doesn't seem to provide any room for the container to be
"automatically-generated".

Paul

On Thu, Sep 20, 2012 at 3:58 PM, Alex Buckley <alex.buckley at oracle.com>wrote:

> I just updated the spec to slightly tighten the two-way relationship
> between a repeatable and a containing annotation type when compiling a
> prospective containing annotation type. Previously, its @ContainerFor
> merely needed to agree with the containee's @ContainedBy, but that allowed
> deformities in the structure of the prospective containing annotation type
> (e.g. the return type of its value() element). In contrast, we always
> required that compiling a prospective repeatable annotation type needed to
> see an @ContainedBy that named a well-formed containing annotation type.
>
> The change is a single paragraph on page 4 of http://cr.openjdk.java.net/~
> **abuckley/8misc.pdf <http://cr.openjdk.java.net/~abuckley/8misc.pdf>,
> and the corresponding reflection rule on page 10. I extended the example on
> page 4 too.
>
> Separately, I would be grateful if any EE engineers on this list could be
> sure they agree with the detailed reflection examples in section 1.2.
>
> Alex
>