JDK 13 RFR of JDK-8224687: Add clarifying overrides of Element.asType to more specific subinterfaces

[Jonathan Gibbons]

On 5/30/19 11:11 AM, Joe Darcy wrote:
> Hi Ron,
>
> On 5/30/2019 10:44 AM, Ron Shapiro wrote:
>> Is it within scope to return the specific subtypes as covariant 
>> return types? e.g. TypeParameterElement could return TypeVariable, 
>> TypeElement could return DeclaredType, etc.
>>
> Based on experience with the earlier apt API, it was a conscious 
> design choice for javax.lang.model to not use covariant returns in a 
> case like this even though it seems appealing. The issue is the that 
> the javax.lang.model is intended to be implemented by different 
> compilers, including compilers where the native declaration and type 
> hierarchies don't match the declaration and type hierarchies in the 
> javax.lang.model modeling interfaces. In particular, some compilers 
> might want to use a single type to implement many (or all) of the 
> javax.lang.model.element interfaces. Having covariant overrides would 
> interfere with such a reduced-type design.
>
> HTH,
>
> -Joe
>
Joe,

I'm not sure I buy this variant of the "some compilers might want to use 
a single type" argument.

If the "kind" (ElementKind or TypeKind) of the return is always a 
specific kind, then there is a presumption that it is safe to downcast 
the returned object to the corresponding specific subtype. That could be 
done equally well (or better) by declaring the return type of the method 
to be more specific.

I understand the "some compilers might want to use a single type" 
argument, but that would only apply to internal implementation types, 
and surely not would not absolve the compiler from the responsibility of 
implementing specific subtypes where appropriate.  In other words, there 
should be specified correspondence between "kind" and implemented 
interfaces.

-- Jon