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