Field of wildcard parameterized class is passed to anonymous class created with diamond; JDK bug?
Georgiy Rakov
georgiy.rakov at oracle.com
Wed May 27 15:36:02 UTC 2015
I filed the issue for this case:
https://bugs.openjdk.java.net/browse/JDK-8081318
Thank you,
Gerogiy.
On 13.05.2015 13:07, Maurizio Cimadamore wrote:
> 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/20150527/248ac382/attachment.html>
More information about the compiler-dev
mailing list