trailing comment

[michael keith]

Hi Alex,

I went over the latest document and it all looks pretty good to me. Just 
one additional comment, and a minor question, of sorts.

- p. 4 - Is there a use case for allowing @FooContainer to be 
@Documented/@Inherited when @Foo is not? In most cases seemingly 
arbitrary limitations are bad, but in this case I don't see a need for 
allowing it, and it might actually be detrimental to do so. For example, 
if I make a mistake as the annotation developer and during the course of 
development I no longer want @Foo to be @Inherited so I remove the 
meta-annotation from @Foo but forget to remove it from @FooContainer. 
When a user goes to use @Foo and annotates their UserClass with it their 
UserSubClass won't see it, as expected. However, if they add another 
@Foo then both will be wrapped in a @FooContainer and now UserSubClass 
will be able to see them using getAllAnnotations(Foo.class) because the 
container is inherited. I am just wondering if the feature was motivated 
by a case that someone thought would be useful, or if it was a case of 
trying not to impose unnecessary limitations. In general I am concerned 
about the maintenance issue of keeping the two annotations in sync. If 
they are allowed to be out of sync then the IDE won't be able to help me.
Note 1: I can see the use case for different @Targets, (although I tend 
to believe it will be an unusual one) I'm just missing the usefulness of 
different @Inherited/@Documented settings.
Note 2: Because container annotations is purely a mechanism to enable 
multiple contained annotations in EE specs, we don't actually have any 
meta-annotation differences between the containing and the contained 
annotations at all. In other words, my vision of container annotations 
may be biased towards them being distinctly unsophisticated.

- p. 6 - The note after the first para in 9.7 states:
     "This rule implements the policy that an annotation may repeat at 
only some of the locations where the annotation may appear. See §9.6 for 
more details."
I don't see how the first para of 9.7 defines that behavior. Am I 
missing something? (It is defined in section 9.6 by the allowance of 
different Targets, in any case.)

-Mike

P.S.  I'm not sure what parts, if any, of the document you are planning 
on lifting and using in the specs but here are some typos that I noticed 
as well (just in case it gets copied to a spec).

- p. 9 - Feels like a typo, but the para that begins:  "An annotation A 
is directly present on an element E if ... " should finish by saying  
"... contains exactly one annotation C whose type is the containing 
annotation type of A's type (§9.6) and whose value element contains *at 
least one annotation of type* A."

- p. 18 - Cut/paste typo in para that begins: "Now suppose Foo is made 
repeatable ...". The bracketed part should be removed since it was 
stated above that FooContainer was inheritable (Foo may or may not be 
inheritable).

- p. 18 - Missing closing bracket in 
"B.class.getAllDeclaredAnnotations(FooContainer.class = [ ]"