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

[Srikanth]

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/fe5b34f1/attachment.html>