spec clarification: wildcard array element signature

[Dan Smith]

> On Feb 7, 2017, at 12:38 PM, Alex Buckley <alex.buckley at oracle.com> wrote:
> 
> On 2/7/2017 10:54 AM, Dan Smith wrote:
>> 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.
> 
> Am I right to say that this is what javac is doing in the recent snipper from Stephan Herrmann? :-
> 
> ---
> public class Bug494198<T> { class Inner<U> {...} }
> 
> Bug494198<?> outer = ...
> ... outer.new Inner<String>() {...}
> 
> final class Bug494198$1
>  extends ***Bug494198<<captured wildcard>>***.Inner<java.lang.String>
> ---

Yep, same issue. Odd that javac uses capture in this case while using a wildcard in the other case, but it comes down to the same lack of a spec.

>> 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.
> 
> OK -- please close it with an explanation for Liam and Stephan's benefit.

Done.

—Dan