interactions between type annotations and language model APIs.
joe.darcy at oracle.com
Fri May 9 15:24:52 UTC 2014
On 5/5/2014 1:48 PM, Alex Buckley wrote:
> On 5/5/2014 12:52 PM, Jonathan Gibbons wrote:
>> In particular, TypeMirror is now an AnnotatedConstruct, and various
>> methods in javax.lang.model.util.Types return computed TypeMirrors --
>> for example, capture(TypeMirror), directSupertypes(TypeMirror),
>> erasure(TypeMirror), etc.
> Right, because jx.l.m.t.TypeMirror always represented the use of a
> type at a particular location in source - which can now usually be
>> In cases where the argument has type annotations, what type annotations
>> (if any) should appear on the return value?
>> It would help to see clarification added to the specifications, either
>> generally, or on a case-by-case basis for the affected methods.
> To be specific, the "generator" methods in jx.l.m.u.Types are these ten:
> getDeclaredType x2
> Generally, the "correct" thing to do would be to inspect the
> TypeMirror argument and thread its type annotations into the
> TypeMirror result. But not always: just because '@Foo String' appears
> in source does not mean that calling directSupertypes on its mirror
> should return '@Foo Object'. There is also a limitation of the API for
> wildcard annotations: getWildcardType could produce a mirror for '?
> extends @Foo ...' and '? super @Foo ...' but not '@Foo ? extends ...'
> or '@Foo ? super ...'.
> Joe, what is your view on retrofitting type annotations into Types?
My first reaction here is that these methods should by default ignore
annotations and we should add another utility method or two like:
<T extends TypeMirror> T withAnnotations(T typeMirror, List<? extends
<T extends TypeMirror> T withAnnotations(T typeMirror,
to allow the annotations savvy user to perform whatever annotation
passing along or computation is appropriate for the problem domain.
More information about the compiler-dev