interactions between type annotations and language model APIs.

Jonathan Gibbons jonathan.gibbons at oracle.com
Sat May 10 00:03:38 UTC 2014


On 05/09/2014 03:59 PM, Alex Buckley wrote:
> On 5/9/2014 3:38 PM, Joe Darcy wrote:
>> Given the desired semantics of the annotations being used in these cases
>> are largely extra-lingual, I don't think trying to specify their
>> propagation in javax.lang.model is wise.
>
> Clearly, general TypeMirror combinators in jx.l.m.u.Types are not 
> expected to be sensitive to the meaning of type annotations. For 
> example, isSameType is not expected to compare type annotations within 
> its two TypeMirror arguments.
>
> But while the _semantics_ of the annotations are extra-lingual, their 
> _existence_ is not. That's why I called out specific TypeMirror 
> generators in jx.l.m.u.Types. For example, if I have a TypeMirror that 
> represents '@Foo List<String>', and I pass it to the erasure method, 
> then I could reasonably expect to get back a TypeMirror that 
> represents '@Foo List'. Similarly for getArrayType, getDeclaredType, etc.
>
> All that said, preserving the existence of type annotations in all 
> TypeMirror generators is quite complicated.
>
>> For tracking purposes, a JBS bug in core-libs / javax.lang.model would
>> be appropriate.
>
> It's not clear to me what the actual behavior of Types' methods is 
> today, which is why I proposed to specify that it's not specified 
> (inspired by Class#getDeclaredMethods being specified to return 
> methods in an unspecified order).
>
> Jon, Eric, would that be OK?
>
> Alex

It seems to me that specifying the behavior to be unspecified is (a) 
avoiding the issue and (b) not helpful to clients.

It's one thing to say the order of methods in a class is unspecified, 
when it is clear that no semantic change occurs if they are shuffled, 
but it is another to say, "eh, they may be there, they may not be 
there".  Any client wanting to build deterministic behavior on top of an 
API like that now has to deal with the possibility that none, some or 
all of the annotations may survive the call.

I like your differentiation between the semantics of type annotations 
and the existence of type annotations. I think the spec-gurus for 
javax.lang.model, having determined that the number of generator methods 
is countable on their two hands, could determine a boolean value for 
each finger and give a thumbs up or thumbs down as to whether the annos 
survive the call.

If in doubt, specify that none survive, and give clients a determinsitic 
base on which to build their own type systems.

-- Jon


More information about the compiler-dev mailing list