spec clarification: wildcard array element signature

Alex Buckley alex.buckley at oracle.com
Thu Nov 3 23:24:53 UTC 2016


On 10/24/2016 2:35 PM, Maurizio Cimadamore wrote:
> On 24/10/16 19:28, Alex Buckley wrote:
> Regarding the other issue about wildcards being replaced in supertypes,
> I think there are two options - none of which is particularly appealing:
>
> 1. fix javac (and other compilers) so that the signature attribute only
> speaks about types in the source code, w/o attempting to do any
> membership computation - this should ensure that non-denotable types
> should not crop up in the process - unfortunately, doing so will change
> the signature attribute of real code out there - and the compatibility
> impact potentially large (the difference will be visible in core
> reflection).

The Signature attribute, in particular a class type signature (JVMS8 
4.7.9.1), is defined in terms of binary names, as alluded to by your 
comment about Field.getGenericType aligning with Field.getType.

Therefore, Signature must be able to encode  A<?[]>.I  (so to speak) 
rather than the  B<?>.I  type literally found in source code.

That means rejecting option 1, and choosing option 2:

> 2. keep javac as is - live with 'weird' signatures and plug resulting
> soundness issues (esp. around separate compilation) ?

Which means a change to the JVMS TypeArgument production, and 
corresponding enhancement to ParameterizedType.getActualTypeArguments() 
[thanks Liam].

Dan, any objection to this?

Alex


More information about the compiler-dev mailing list