spec clarification: wildcard array element signature

[Dan Smith]

> 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
>> 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?

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.

—Dan