spec clarification: wildcard array element signature

[Stephan Herrmann]

If I understand correctly, the situation discussed here should be
avoided by future changes in JLS, right?
Until then, compilers are free to generate anything they want
when they encounter such situations?

Let me add that the original discussion [1] regarding ecj started with
a slightly different example, where inference computes the type of a
lambda parameter to a capture, and then creating an LVTT was creating
trouble: javac would simply not generate such an entry, although it
seems to be recommended to generate one, whereas ecj generates an
LVTT with inevitably unspec'ed encoding.

Will that situation, too, be avoided by future JLS changes?
I imagine that not only "captures" are concerned, but likely also
those "fresh type variables" that are introduced in JSL 18.4.
What happens when Java gets type inference for local variables?
Can we be sure that none of this will have to show up in class files?
Will there, e.g., be rules about when generating LVTT entries should
be avoided?
Or is there perhaps more to it?

thanks,
Stephan

[1] http://stackoverflow.com/questions/37268391/strange-entry-in-localvariabletypetable-when-compiling-with-eclipse-compile

> 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>
> ---
>
>> 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.
>
> Alex