Uploaded image for project: 'JDK'
  1. JDK
  2. JDK-8176577

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

    Details

      Description

      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.

        Issue Links

          Activity

          Hide
          sadayapalam Srikanth Adayapalam added a comment -
          We discussed this in the javac team and the emerging consensus is that this is really a corner case territory - Since this realistically affects only anon diamond in unchecked method call context, it should be ok to defer. It is also very late in the game for making any risky changes - given it is a more than a decade since the gentle and not so gentle nudge away from raw types has been in force, this does not look to me the kind of issue that needs addressal at this point in the release cycle.
          Show
          sadayapalam Srikanth Adayapalam added a comment - We discussed this in the javac team and the emerging consensus is that this is really a corner case territory - Since this realistically affects only anon diamond in unchecked method call context, it should be ok to defer. It is also very late in the game for making any risky changes - given it is a more than a decade since the gentle and not so gentle nudge away from raw types has been in force, this does not look to me the kind of issue that needs addressal at this point in the release cycle.
          Hide
          mtrudeau Michel Trudeau added a comment - - edited
          9-defer-request justification:
          This is a corner case, it only affects anonymous diamond in unchecked method call context. It is low priority and risky to fix at this point in the release cycle.
          - This is an ILW P3 bug.
          Show
          mtrudeau Michel Trudeau added a comment - - edited 9-defer-request justification: This is a corner case, it only affects anonymous diamond in unchecked method call context. It is low priority and risky to fix at this point in the release cycle. - This is an ILW P3 bug.

            People

            • Assignee:
              sadayapalam Srikanth Adayapalam
              Reporter:
              grakov Georgiy Rakov
            • Votes:
              0 Vote for this issue
              Watchers:
              5 Start watching this issue

              Dates

              • Created:
                Updated: