Field of wildcard parameterized class is passed to anonymous class created with diamond; JDK bug?

[Maurizio Cimadamore]

This is indeed long-standing javac behavior - also commented in the code:

/**
  * javac has a long-standing 'simplification' (see 6391995):
  * given an actual argument type, the method check is performed
  * on its upper bound. This leads to inconsistencies when an
  * argument type is checked against itself. For example, given
  * a type-variable T, it is not true that {@codeU(T)<: T},
  * so we need to guard against that.
  */


At some point this should be cleaned up - but there could be non-trivial 
compatibility concerns there.

Maurizio

On 13/05/15 04:54, Srikanth wrote:
> Hi Georgiy,
>
> Thanks for the test case.
>
> This seems to be long standing behaviour in javac inference that 
> surfaces with <> only when combined with anonymous classes.
>
> With diamond and with or without anonymous classes,
>
> i.e in both
>
> newCls<>(a.f);
> newCls<>(a.f) {}
>
>
> the elided type is inferred to be jlO and hence we don't report an error.
>
> I will double check whether inference is doing the right thing here. I see
> that ECJ infers the elided type to be Cls<capture#1-of ? extends java.lang.Object>
>
> I'll either post a concluding clarification or raise a suitable JBS ticket to
> follow up.
>
> Thanks!
> Srikanth
> On Tuesday 12 May 2015 06:53 PM, Georgiy Rakov wrote:
>> Hello,
>>
>> let's consider following example:
>>
>>     classPar<U> {
>>          Uf;
>>     }
>>
>>     classCls<T> {
>>          Cls(Tt) {}
>>     }
>>
>>     public classTest70  {
>>          public static voidtest() {
>>              Par<?> a =newPar<>();
>>              newCls<>(a.f) { };
>>          }
>>     }
>>
>> JDK9b60 compiles it successfully however according to my 
>> understanding compilation should have failed because:
>>
>> 1. The type of 'a' local variable is a parameterized type Par<?>.
>> 2. According to following assertion from JLS 4.5.2 the type of the 
>> field "f" of Par<?> is a fresh capture variable: null-type <: CAP <: 
>> Object:
>>
>>     If any of the type arguments in the parameterization of Care
>>     wildcards, then: 
>>
>>      o
>>
>>         The types of the fields, methods, and constructors in C|<|T_1
>>         ,...,T_n |>|are the types of the fields, methods, and
>>         constructors in the capture conversion of C|<|T_1 ,...,T_n
>>         |>|(§5.1.10
>>         <http://docs.oracle.com/javase/specs/jls/se8/html/jls-5.html#jls-5.1.10>).
>>
>>
>> 3. 'new Cls<>(a.f) { }' causes T to be inferred as capture variable 
>> CAP presented in step 2.
>> 4. According to following new assertion presented in JDK-8073593 
>> issue comment 
>> <https://bugs.openjdk.java.net/browse/JDK-8073593?focusedCommentId=13622110&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13622110>compilation 
>> error should occur because superclass of the anonymous class is 
>> inferred as a type parameterized by type variable that was not 
>> declared as a type parameter (the capture variable CAP).
>>
>>     ***/_*It is a compile-time error*_/ if the superclass or
>>     superinterface type of the anonymous class, T, or any
>>     subexpression of T, has one of the following forms:
>>     - A /_*type variable (4.4) that was not declared as a type
>>     parameter*_/ (such as /_*a type variable produced by capture
>>     conversion*_/ (5.1.10))
>>     - An intersection type (4.9)
>>     - A class or interface type, where the class or interface
>>     declaration is not accessible from the class or interface in
>>     which the expression appears.***
>>     The term "subexpression" includes type arguments of parameterized
>>     types (4.5), bounds of wildcards (4.5.1), and element types of
>>     array types (10.1). It excludes bounds of type variables.***
>>
>> Could you please tell if you agree that this is really a JDK bug.
>>
>> Thank you,
>> Georgiy. 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20150513/6cde7046/attachment.html>