trailing comment

[Joe Darcy]

Hi Mike,

On 1/7/2013 7:03 PM, michael keith wrote:
> 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.)

On the current @Target policy, in the early iterations of the proposal 
[1], the subset/superset relation was the opposite of what is specified 
now.  The change was made after we examined Foo / Foos annotation type 
pairs in the EE specs and noticed that by design that some annotations 
were meant to only be selectively repeatable.

Expanding such an investigation more thoroughly, it would be helpful for 
the existing EE annotation types to be retrofitted to use the 
in-progress compiler support for this pattern to verify how well the 
current language rules support the existing types.

Thanks,

-Joe

[1] https://blogs.oracle.com/darcy/entry/repeating_annotations_in_the_works