Quantcast

Anonymous class instance creation expression with diamond compatibility constraint is reduced to anonymous class type?

classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Anonymous class instance creation expression with diamond compatibility constraint is reduced to anonymous class type?

Georgiy Rakov
Hello,

let's consider following code:

class MyType<T> {}

class MyList<T> {
     MyList<T> copyThis() { return null; }
}

class Foo<T> {
     Foo(MyType<String> a){ }
}

public class Test26  {
     public static void main(String argv[]) {
         MyList<Foo> l1 = new MyList<>();
         m2(l1, m1(
                    new Foo<>(new MyType()){ }
                  ).copyThis());
     }
     public static <T> MyList<T> m2(MyList<T> l1, MyList<T> l2) { return
null; }
     public static <U> MyList<U> m1(U item) { return null; }
}

it fails to compile by javac from JDK 9 build 160 with following error:

Error:(15, 11) java: incompatible types: inference variable T has
incompatible equality constraints <anonymous Foo>,Foo

But it seems that this code should compile successfully because:

1. When performing invocation type inference for m1 invocation, a
temporary method is chosen according to following assertion from 18.2.1:

If the expression is a class instance creation expression or a method
invocation expression, the constraint reduces to the bound set B3 which
would be used to determine the expression's invocation type when
targeting T, as defined in §18.5.2. (For a class instance creation
expression, the corresponding "method" used for inference is defined in
§15.9.3).

2. The temporary method return type is an anonymous class superclass as
it's specified by following assertions from 15.9.3 JLS 9 draft:

... If C is an anonymous class, let D be the superclass or
superinterface of C named by the class instance creation expression.

The return type of mj is θj applied to D<F1,...,Fp>.

3. So the return type of the temporary method is Foo<F1>.

4. Unchecked conversion is necessary in order for constructor Foo to be
applicable so the return type D is erased and should be Foo.

5. Thus m1 inference variable U should be inferred as Foo and m1 return
type should be inferred as MyList<Foo>.

6. Finally m2 inference variable T should be inferred as Foo with no
incompatible constraints.

Is it javac bug?

Thank you,

Georgiy.



Test26.java (690 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Anonymous class instance creation expression with diamond compatibility constraint is reduced to anonymous class type?

Maurizio Cimadamore
Hi Georgiy - thanks for the report. Just so that I understand - is this
a regression or is it a new test and that's the behavior you are seeing
with the latest build? I'm asking because I don't recall recent changes
in this area.

That said, I think your analysis looks correct - the spec draft calls
for the anonymous inner class non-denotable type to be 'normalized'.

Maurizio

On 10/03/17 20:02, Georgiy Rakov wrote:

> class MyType<T> {}
>
> class MyList<T> {
>     MyList<T> copyThis() { return null; }
> }
>
> class Foo<T> {
>     Foo(MyType<String> a){ }
> }
>
> public class Test26  {
>     public static void main(String argv[]) {
>         MyList<Foo> l1 = new MyList<>();
>         m2(l1, m1(
>                    new Foo<>(new MyType()){ }
>                  ).copyThis());
>     }
>     public static <T> MyList<T> m2(MyList<T> l1, MyList<T> l2) {
> return null; }
>     public static <U> MyList<U> m1(U item) { return null; }
> }

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Anonymous class instance creation expression with diamond compatibility constraint is reduced to anonymous class type?

B. Blaser
Hi,

On 10 March 2017 at 22:46, Maurizio Cimadamore
<[hidden email]> wrote:
> Hi Georgiy - thanks for the report. Just so that I understand - is this a
> regression or is it a new test and that's the behavior you are seeing with
> the latest build? I'm asking because I don't recall recent changes in this
> area.
>
> That said, I think your analysis looks correct - the spec draft calls for
> the anonymous inner class non-denotable type to be 'normalized'.
>
> Maurizio

The problem seems to be present since build 82, 136, 152 and rev
a21e5b9dc5c3 (1.5 month ago).

Next is a patch that corrects this specific case upon rev a21e5b9dc5c3
(needs to be well tested).
It 'normalizes' T when checking for same type (Types.isSameType(),
Types.SameTypeVisitor.visitClassType() and
Types.SameTypeVisitor.visitUndetVar()).

Bernard

diff --git a/src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java
b/src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java
--- a/src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java
+++ b/src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java
@@ -1022,6 +1022,20 @@
                 isSameTypeStrict.visit(t, s) :
                 isSameTypeLoose.visit(t, s);
     }
+    private Type normalize(Type t) {
+        if (t.tsym.name.isEmpty()) {
+            // Anonymous class
+            ClassType norm = (ClassType) t.tsym.type;
+            if (norm == null)
+                return null;
+            else if (norm.interfaces_field != null &&
norm.interfaces_field.nonEmpty())
+                return norm.interfaces_field.head;
+            else
+                return norm.supertype_field;
+        }
+        else
+            return t;
+    }
     // where
         abstract class SameTypeVisitor extends TypeRelation {

@@ -1070,7 +1084,7 @@

             @Override
             public Boolean visitClassType(ClassType t, Type s) {
-                if (t == s)
+                if (normalize(t) == normalize(s))
                     return true;

                 if (s.isPartial())
@@ -1152,7 +1166,7 @@
                     return true;
                 }

-                t.addBound(InferenceBound.EQ, s, Types.this);
+                t.addBound(InferenceBound.EQ, normalize(s), Types.this);

                 return true;
             }

> On 10/03/17 20:02, Georgiy Rakov wrote:
>>
>> class MyType<T> {}
>>
>> class MyList<T> {
>>     MyList<T> copyThis() { return null; }
>> }
>>
>> class Foo<T> {
>>     Foo(MyType<String> a){ }
>> }
>>
>> public class Test26  {
>>     public static void main(String argv[]) {
>>         MyList<Foo> l1 = new MyList<>();
>>         m2(l1, m1(
>>                    new Foo<>(new MyType()){ }
>>                  ).copyThis());
>>     }
>>     public static <T> MyList<T> m2(MyList<T> l1, MyList<T> l2) { return
>> null; }
>>     public static <U> MyList<U> m1(U item) { return null; }
>> }
>
>
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Anonymous class instance creation expression with diamond compatibility constraint is reduced to anonymous class type?

Maurizio Cimadamore


On 11/03/17 15:05, B. Blaser wrote:

> Hi,
>
> On 10 March 2017 at 22:46, Maurizio Cimadamore
> <[hidden email]> wrote:
>> Hi Georgiy - thanks for the report. Just so that I understand - is this a
>> regression or is it a new test and that's the behavior you are seeing with
>> the latest build? I'm asking because I don't recall recent changes in this
>> area.
>>
>> That said, I think your analysis looks correct - the spec draft calls for
>> the anonymous inner class non-denotable type to be 'normalized'.
>>
>> Maurizio
> The problem seems to be present since build 82, 136, 152 and rev
> a21e5b9dc5c3 (1.5 month ago).
Uhm - I looked at  a21e5b9dc5c3, and all I found is this:

http://hg.openjdk.java.net/jdk9/dev/langtools/rev/a21e5b9dc5c3

Which seems unlikely to cause inference issues?
>
> Next is a patch that corrects this specific case upon rev a21e5b9dc5c3
> (needs to be well tested).
> It 'normalizes' T when checking for same type (Types.isSameType(),
> Types.SameTypeVisitor.visitClassType() and
> Types.SameTypeVisitor.visitUndetVar()).
I believe the issue should be addressed in a more direct way - as per
Georgiy's evaluation, the spec draft says that the type of

new Foo<>() { ... }

is simply Foo, not an anonymous type. So normalization should never be
needed during type-checking.

Maurizio

>
> Bernard
>
> diff --git a/src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java
> b/src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java
> --- a/src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java
> +++ b/src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java
> @@ -1022,6 +1022,20 @@
>                   isSameTypeStrict.visit(t, s) :
>                   isSameTypeLoose.visit(t, s);
>       }
> +    private Type normalize(Type t) {
> +        if (t.tsym.name.isEmpty()) {
> +            // Anonymous class
> +            ClassType norm = (ClassType) t.tsym.type;
> +            if (norm == null)
> +                return null;
> +            else if (norm.interfaces_field != null &&
> norm.interfaces_field.nonEmpty())
> +                return norm.interfaces_field.head;
> +            else
> +                return norm.supertype_field;
> +        }
> +        else
> +            return t;
> +    }
>       // where
>           abstract class SameTypeVisitor extends TypeRelation {
>
> @@ -1070,7 +1084,7 @@
>
>               @Override
>               public Boolean visitClassType(ClassType t, Type s) {
> -                if (t == s)
> +                if (normalize(t) == normalize(s))
>                       return true;
>
>                   if (s.isPartial())
> @@ -1152,7 +1166,7 @@
>                       return true;
>                   }
>
> -                t.addBound(InferenceBound.EQ, s, Types.this);
> +                t.addBound(InferenceBound.EQ, normalize(s), Types.this);
>
>                   return true;
>               }
>
>> On 10/03/17 20:02, Georgiy Rakov wrote:
>>> class MyType<T> {}
>>>
>>> class MyList<T> {
>>>      MyList<T> copyThis() { return null; }
>>> }
>>>
>>> class Foo<T> {
>>>      Foo(MyType<String> a){ }
>>> }
>>>
>>> public class Test26  {
>>>      public static void main(String argv[]) {
>>>          MyList<Foo> l1 = new MyList<>();
>>>          m2(l1, m1(
>>>                     new Foo<>(new MyType()){ }
>>>                   ).copyThis());
>>>      }
>>>      public static <T> MyList<T> m2(MyList<T> l1, MyList<T> l2) { return
>>> null; }
>>>      public static <U> MyList<U> m1(U item) { return null; }
>>> }
>>

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Anonymous class instance creation expression with diamond compatibility constraint is reduced to anonymous class type?

Remi Forax
Hi Maurizio,

----- Mail original -----
> De: "Maurizio Cimadamore" <[hidden email]>
> À: "B. Blaser" <[hidden email]>
> Cc: [hidden email]
> Envoyé: Samedi 11 Mars 2017 22:49:34
> Objet: Re: Anonymous class instance creation expression with diamond compatibility constraint is reduced to anonymous
> class type?

> On 11/03/17 15:05, B. Blaser wrote:
>> Hi,
>>
>> On 10 March 2017 at 22:46, Maurizio Cimadamore
>> <[hidden email]> wrote:
>>> Hi Georgiy - thanks for the report. Just so that I understand - is this a
>>> regression or is it a new test and that's the behavior you are seeing with
>>> the latest build? I'm asking because I don't recall recent changes in this
>>> area.
>>>
>>> That said, I think your analysis looks correct - the spec draft calls for
>>> the anonymous inner class non-denotable type to be 'normalized'.
>>>
>>> Maurizio
>> The problem seems to be present since build 82, 136, 152 and rev
>> a21e5b9dc5c3 (1.5 month ago).
> Uhm - I looked at  a21e5b9dc5c3, and all I found is this:
>
> http://hg.openjdk.java.net/jdk9/dev/langtools/rev/a21e5b9dc5c3
>
> Which seems unlikely to cause inference issues?
>>
>> Next is a patch that corrects this specific case upon rev a21e5b9dc5c3
>> (needs to be well tested).
>> It 'normalizes' T when checking for same type (Types.isSameType(),
>> Types.SameTypeVisitor.visitClassType() and
>> Types.SameTypeVisitor.visitUndetVar()).
> I believe the issue should be addressed in a more direct way - as per
> Georgiy's evaluation, the spec draft says that the type of
>
> new Foo<>() { ... }
>
> is simply Foo, not an anonymous type. So normalization should never be
> needed during type-checking.

You can not do that !

new Object() {  } is typed as the anonymous inner class, not Object,
the goal of the inference, at least for the average guy, is to fill the blank,
the resulting type has to be either the anonymous inner class or we should remove this feature.

>
> Maurizio

Rémi

>>
>> Bernard
>>
>> diff --git a/src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java
>> b/src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java
>> --- a/src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java
>> +++ b/src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java
>> @@ -1022,6 +1022,20 @@
>>                   isSameTypeStrict.visit(t, s) :
>>                   isSameTypeLoose.visit(t, s);
>>       }
>> +    private Type normalize(Type t) {
>> +        if (t.tsym.name.isEmpty()) {
>> +            // Anonymous class
>> +            ClassType norm = (ClassType) t.tsym.type;
>> +            if (norm == null)
>> +                return null;
>> +            else if (norm.interfaces_field != null &&
>> norm.interfaces_field.nonEmpty())
>> +                return norm.interfaces_field.head;
>> +            else
>> +                return norm.supertype_field;
>> +        }
>> +        else
>> +            return t;
>> +    }
>>       // where
>>           abstract class SameTypeVisitor extends TypeRelation {
>>
>> @@ -1070,7 +1084,7 @@
>>
>>               @Override
>>               public Boolean visitClassType(ClassType t, Type s) {
>> -                if (t == s)
>> +                if (normalize(t) == normalize(s))
>>                       return true;
>>
>>                   if (s.isPartial())
>> @@ -1152,7 +1166,7 @@
>>                       return true;
>>                   }
>>
>> -                t.addBound(InferenceBound.EQ, s, Types.this);
>> +                t.addBound(InferenceBound.EQ, normalize(s), Types.this);
>>
>>                   return true;
>>               }
>>
>>> On 10/03/17 20:02, Georgiy Rakov wrote:
>>>> class MyType<T> {}
>>>>
>>>> class MyList<T> {
>>>>      MyList<T> copyThis() { return null; }
>>>> }
>>>>
>>>> class Foo<T> {
>>>>      Foo(MyType<String> a){ }
>>>> }
>>>>
>>>> public class Test26  {
>>>>      public static void main(String argv[]) {
>>>>          MyList<Foo> l1 = new MyList<>();
>>>>          m2(l1, m1(
>>>>                     new Foo<>(new MyType()){ }
>>>>                   ).copyThis());
>>>>      }
>>>>      public static <T> MyList<T> m2(MyList<T> l1, MyList<T> l2) { return
>>>> null; }
>>>>      public static <U> MyList<U> m1(U item) { return null; }
>>>> }
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Anonymous class instance creation expression with diamond compatibility constraint is reduced to anonymous class type?

Srikanth
https://bugs.openjdk.java.net/browse/JDK-8133936 seems to have some
wordings that explains the
rationale.

Srikanth


On Monday 13 March 2017 12:35 PM, Remi Forax wrote:

> Hi Maurizio,
>
> ----- Mail original -----
>> De: "Maurizio Cimadamore" <[hidden email]>
>> À: "B. Blaser" <[hidden email]>
>> Cc: [hidden email]
>> Envoyé: Samedi 11 Mars 2017 22:49:34
>> Objet: Re: Anonymous class instance creation expression with diamond compatibility constraint is reduced to anonymous
>> class type?
>> On 11/03/17 15:05, B. Blaser wrote:
>>> Hi,
>>>
>>> On 10 March 2017 at 22:46, Maurizio Cimadamore
>>> <[hidden email]> wrote:
>>>> Hi Georgiy - thanks for the report. Just so that I understand - is this a
>>>> regression or is it a new test and that's the behavior you are seeing with
>>>> the latest build? I'm asking because I don't recall recent changes in this
>>>> area.
>>>>
>>>> That said, I think your analysis looks correct - the spec draft calls for
>>>> the anonymous inner class non-denotable type to be 'normalized'.
>>>>
>>>> Maurizio
>>> The problem seems to be present since build 82, 136, 152 and rev
>>> a21e5b9dc5c3 (1.5 month ago).
>> Uhm - I looked at  a21e5b9dc5c3, and all I found is this:
>>
>> http://hg.openjdk.java.net/jdk9/dev/langtools/rev/a21e5b9dc5c3
>>
>> Which seems unlikely to cause inference issues?
>>> Next is a patch that corrects this specific case upon rev a21e5b9dc5c3
>>> (needs to be well tested).
>>> It 'normalizes' T when checking for same type (Types.isSameType(),
>>> Types.SameTypeVisitor.visitClassType() and
>>> Types.SameTypeVisitor.visitUndetVar()).
>> I believe the issue should be addressed in a more direct way - as per
>> Georgiy's evaluation, the spec draft says that the type of
>>
>> new Foo<>() { ... }
>>
>> is simply Foo, not an anonymous type. So normalization should never be
>> needed during type-checking.
> You can not do that !
>
> new Object() {  } is typed as the anonymous inner class, not Object,
> the goal of the inference, at least for the average guy, is to fill the blank,
> the resulting type has to be either the anonymous inner class or we should remove this feature.
>
>> Maurizio
> Rémi
>
>>> Bernard
>>>
>>> diff --git a/src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java
>>> b/src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java
>>> --- a/src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java
>>> +++ b/src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java
>>> @@ -1022,6 +1022,20 @@
>>>                    isSameTypeStrict.visit(t, s) :
>>>                    isSameTypeLoose.visit(t, s);
>>>        }
>>> +    private Type normalize(Type t) {
>>> +        if (t.tsym.name.isEmpty()) {
>>> +            // Anonymous class
>>> +            ClassType norm = (ClassType) t.tsym.type;
>>> +            if (norm == null)
>>> +                return null;
>>> +            else if (norm.interfaces_field != null &&
>>> norm.interfaces_field.nonEmpty())
>>> +                return norm.interfaces_field.head;
>>> +            else
>>> +                return norm.supertype_field;
>>> +        }
>>> +        else
>>> +            return t;
>>> +    }
>>>        // where
>>>            abstract class SameTypeVisitor extends TypeRelation {
>>>
>>> @@ -1070,7 +1084,7 @@
>>>
>>>                @Override
>>>                public Boolean visitClassType(ClassType t, Type s) {
>>> -                if (t == s)
>>> +                if (normalize(t) == normalize(s))
>>>                        return true;
>>>
>>>                    if (s.isPartial())
>>> @@ -1152,7 +1166,7 @@
>>>                        return true;
>>>                    }
>>>
>>> -                t.addBound(InferenceBound.EQ, s, Types.this);
>>> +                t.addBound(InferenceBound.EQ, normalize(s), Types.this);
>>>
>>>                    return true;
>>>                }
>>>
>>>> On 10/03/17 20:02, Georgiy Rakov wrote:
>>>>> class MyType<T> {}
>>>>>
>>>>> class MyList<T> {
>>>>>       MyList<T> copyThis() { return null; }
>>>>> }
>>>>>
>>>>> class Foo<T> {
>>>>>       Foo(MyType<String> a){ }
>>>>> }
>>>>>
>>>>> public class Test26  {
>>>>>       public static void main(String argv[]) {
>>>>>           MyList<Foo> l1 = new MyList<>();
>>>>>           m2(l1, m1(
>>>>>                      new Foo<>(new MyType()){ }
>>>>>                    ).copyThis());
>>>>>       }
>>>>>       public static <T> MyList<T> m2(MyList<T> l1, MyList<T> l2) { return
>>>>> null; }
>>>>>       public static <U> MyList<U> m1(U item) { return null; }
>>>>> }

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Anonymous class instance creation expression with diamond compatibility constraint is reduced to anonymous class type?

B. Blaser
Hi,

On 13 March 2017 at 08:54, Srikanth <[hidden email]> wrote:
> https://bugs.openjdk.java.net/browse/JDK-8133936 seems to have some wordings
> that explains the
> rationale.
>
> Srikanth

There is a small difference between Georgiy's example and jdk 8133936
as shown in the commented example here under.

Georgiy's said:

"4. Unchecked conversion is necessary in order for constructor Foo to be
applicable so the return type D is erased and should be Foo."

Which relates to Daniel's comment on jdk 8133936:

"If C is an anonymous class, then the chosen constructor is the constructor of
the anonymous class. The return type is the anonymous class type."

Then:
- in Georgiy's example, the constructor's return type is chosen (due
to unchecked conversion) and javac fails.
- in jdk 8133936 example, the mj's return type is chosen and javac succeeds.

The question is:
- Is this right to use the constructor's return type in Georgiy's
example instead of mj's return type?

Bernard

class List<T> {
    List() {}
    List<T> getThis() {
        return new List();
    }
}
class MyType<T> {}
class Foo<T> {
//    public Foo(T a1){}
    public Foo(MyType<String> a1){}
}
public class Test25 {
    public static <T> List<T> m1(T item) {
        List l = new List();
        return l;
    }
    public static <U> void m2(List<U> list1, List<U> list2) { }
    public static void test() {
//        m2(new List<Foo<String>>(), m1(new Foo<>("str"){ }).getThis());
        m2(new List<Foo>(), m1(new Foo<>(new MyType()){ }).getThis());
    }
}
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Anonymous class instance creation expression with diamond compatibility constraint is reduced to anonymous class type?

B. Blaser
On 13 March 2017 at 13:00, B. Blaser <[hidden email]> wrote:

> Hi,
>
> On 13 March 2017 at 08:54, Srikanth <[hidden email]> wrote:
>> https://bugs.openjdk.java.net/browse/JDK-8133936 seems to have some wordings
>> that explains the
>> rationale.
>>
>> Srikanth
>
> There is a small difference between Georgiy's example and jdk 8133936
> as shown in the commented example here under.
>
> Georgiy's said:
>
> "4. Unchecked conversion is necessary in order for constructor Foo to be
> applicable so the return type D is erased and should be Foo."
>
> Which relates to Daniel's comment on jdk 8133936:
>
> "If C is an anonymous class, then the chosen constructor is the constructor of
> the anonymous class. The return type is the anonymous class type."
>
> Then:
> - in Georgiy's example, the constructor's return type is chosen (due
> to unchecked conversion) and javac fails.
> - in jdk 8133936 example, the mj's return type is chosen and javac succeeds.
>
> The question is:
> - Is this right to use the constructor's return type in Georgiy's
> example instead of mj's return type?

To resume:
- if Foo isn't generic (or erased), the constructor's return type
<anonymous Foo> is used. For example:

    class Foo {}
    m2(new List<Foo>(), m1(new Foo(){ }).getThis());

  also fails to compile.

- if Foo is generic, the mj's return type Foo<String> is used.

Which seems to be compliant with JLS 15.9.3; but the behavior isn't
absolutely orthogonal between generic and non-generic types as it
seems to be driven by inference needs... See Daniel's comment on jdk
8133936:

"This is pretty messy, but there's a reason for it: we can't really talk about a
class type '[anonymous Foo<___>]' until we can fill in the blank."

Bernard

> class List<T> {
>     List() {}
>     List<T> getThis() {
>         return new List();
>     }
> }
> class MyType<T> {}
> class Foo<T> {
> //    public Foo(T a1){}
>     public Foo(MyType<String> a1){}
> }
> public class Test25 {
>     public static <T> List<T> m1(T item) {
>         List l = new List();
>         return l;
>     }
>     public static <U> void m2(List<U> list1, List<U> list2) { }
>     public static void test() {
> //        m2(new List<Foo<String>>(), m1(new Foo<>("str"){ }).getThis());
>         m2(new List<Foo>(), m1(new Foo<>(new MyType()){ }).getThis());
>     }
> }
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Anonymous class instance creation expression with diamond compatibility constraint is reduced to anonymous class type?

Georgiy Rakov
In reply to this post by Maurizio Cimadamore
Hi Maurizio,

this example can be considered as a new test which resulted from
correcting existing test stemmed from Dan's comment in JDK-8133936. This
behavior is reproduced on JDK build 160.

As it follows from your reply it's likely to be a javac issue, so I've
filed a bug: JDK-8176577.

Thanks,

Georgiy.


On 11.03.2017 0:46, Maurizio Cimadamore wrote:

> Hi Georgiy - thanks for the report. Just so that I understand - is
> this a regression or is it a new test and that's the behavior you are
> seeing with the latest build? I'm asking because I don't recall recent
> changes in this area.
>
> That said, I think your analysis looks correct - the spec draft calls
> for the anonymous inner class non-denotable type to be 'normalized'.
>
> Maurizio
>
> On 10/03/17 20:02, Georgiy Rakov wrote:
>> class MyType<T> {}
>>
>> class MyList<T> {
>>     MyList<T> copyThis() { return null; }
>> }
>>
>> class Foo<T> {
>>     Foo(MyType<String> a){ }
>> }
>>
>> public class Test26  {
>>     public static void main(String argv[]) {
>>         MyList<Foo> l1 = new MyList<>();
>>         m2(l1, m1(
>>                    new Foo<>(new MyType()){ }
>>                  ).copyThis());
>>     }
>>     public static <T> MyList<T> m2(MyList<T> l1, MyList<T> l2) {
>> return null; }
>>     public static <U> MyList<U> m1(U item) { return null; }
>> }
>

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Anonymous class instance creation expression with diamond compatibility constraint is reduced to anonymous class type?

Dan Smith-17

> On Mar 13, 2017, at 8:45 AM, Georgiy Rakov <[hidden email]> wrote:
>
> Hi Maurizio,
>
> this example can be considered as a new test which resulted from correcting existing test stemmed from Dan's comment in JDK-8133936. This behavior is reproduced on JDK build 160.
>
> As it follows from your reply it's likely to be a javac issue, so I've filed a bug: JDK-8176577.

To clarify some confusion in this thread: I agree with Georgiy's interpretation of the spec. The test program he provided should compile. This is consistent with my comment on JDK-8133936.

—Dan
Loading...