Tweaking the language model API for repeating annotations

[Alex Buckley]

We discovered two small issues with section 1.3 of the spec:


1. The spec proposes a new method, Element.getAnnotations().

This method is proposed for consistency with 
AnnotatedElement.getAnnotations(), but it turns out to be difficult to 
implement in the context of the language model. The problem is that, at 
compile-time, there might not be instances of Class objects for the 
annotations we try to look at. The other new methods - 
Element.getAnnotation[s](Class<T>) - do not have this issue since their 
callers must supply a Class object.

It would be possible for Element.getAnnotations() to throw exceptions if 
necessary Class objects were not found, but there is no good unchecked 
exception type available in the language model API. It would also be 
possible to skip over annotations for which Class objects are 
unavailable, and return incomplete results, but this seems undesirable.

I propose to drop the method. Essentially, it's fine in core reflection 
but too brittle for the language model.


2. The spec proposes to refine Element.getAnnotationMirrors() and 
Elements.getAllAnnotationMirrors().

If the language model API only has a class file available for the 
element on which annotation mirrors are requested, then the API cannot 
be sure that it's right to "look through" @FooContainer (if directly 
present on the element) and return @Foo mirrors.

This is true even if FooContainer is a well-formed containing annotation 
type available to the API. The source code of the element - which the 
API strives to reflect - could literally have said @FooContainer(...). 
Unfortunately, a compiler has no way to mark a container annotation as 
"synthesized" during class file generation.

It would be possible to adopt a policy of always looking through 
container annotations on an element. This requires the language model 
API to recognize container annotations, which in turn requires loading 
the annotation's class file, which might not always be available.

I propose to adopt this policy, while allowing the methods to sometimes 
expose container annotations even if not present in source code.


Alex