spec clarification: wildcard array element signature
daniel.smith at oracle.com
Tue Feb 7 18:54:05 UTC 2017
> On Nov 3, 2016, at 5:24 PM, Alex Buckley <alex.buckley at oracle.com> wrote:
> 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
> The Signature attribute, in particular a class type signature (JVMS8 22.214.171.124), 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?
Sorry, didn't see this originally, thanks for pointing me to it.
Yes, I object! "?" is not a type. It's meaningless.
It is always wrong to perform substitutions that replace type variables with wildcards. javac has a history of doing so, and those cases need to be fixed. The compiler's internal representation of wildcards should not even allow such an attempt at substitution to compile (e.g., a class Wildcard should not extend a class Type), but alas, we have a lot of legacy violating this rule.
Liam's program raises issues related to two existing spec bugs:
JDK-8030746: 4.10: Define subtyping for inner classes of parameterized types
JDK-8016196: Inference: define supertype parameterization for wildcard-parameterized types
These are part of our type system cleanup effort; when addressed, we'll have a clear answer for how to interpret "B<?>.I" and, thus, how to record it in bytecode. (Preview: the answer is probably "A<? extends Object>.I".)
Suggest closing JDK-8172742 as "Not an Issue"—the JVMS grammar is fine.
More information about the compiler-dev