interactions between type annotations and language model APIs.
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?
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.
More information about the compiler-dev