<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=utf-8">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    <p>Hi,<br>
      I agree that there's a bug somewhere in javac's code generation -
      but I believe this fix is too wide, as it touches how erasure of
      all cast expression is performed. I think this issue has only to
      do with the synthetic receiver parameter of a method reference,
      which seems to be captured incorrectly. That is, the lambda
      translation machinery knows well that the receiver ought to be AB
      (in fact that's what ends up in the metafactory protocol), but
      when the receiver argument is captured, no cast is emitted.</p>
    <p>I think this could be just matter of generating the right
      checkcast at the right time.</p>
    <p>More specifically, in LambdaToMethod, I see this (method
      visitReference):</p>
    <p>            case BOUND:             /** Expr :: instMethod */<br>
                      init = tree.getQualifierExpression();<br>
    </p>
    <p>Now, since this will simply get the (erased) qualifier expression
      and pass it to the indy as its dynamic argument, we have to handle
      cases where there's a disconnect between the erased type of the
      qualifier expression and the expected receiver type
      (tree.sym.owner.type). I think you need a call to
      transTypes.coerce (as done in other places) at that point, to
      ensure the receiver arg conforms with what the MH expects.</p>
    <p>Maurizio<br>
    </p>
    <br>
    <div class="moz-cite-prefix">On 15/08/18 16:04, Vicente Romero
      wrote:<br>
    </div>
    <blockquote type="cite"
      cite="mid:3228c3c1-efa1-6e9f-7719-8f767582098c@oracle.com">
      <meta http-equiv="Content-Type" content="text/html; charset=utf-8">
      Please review the fix for [1] at [2]. The fix is modifying the way
      intersection types are erased. Javac erases an intersection type
      to its first component, but it is not always the right choice.
      This patch fixes that issue. As an additional information please
      check Dan's comments in the bug entry,<br>
      <br>
      Thanks,<br>
      Vicente<br>
      <br>
      [1] <a class="moz-txt-link-freetext"
        href="https://bugs.openjdk.java.net/browse/JDK-8207320"
        moz-do-not-send="true">https://bugs.openjdk.java.net/browse/JDK-8207320</a><br>
      [2] <a class="moz-txt-link-freetext"
href="http://cr.openjdk.java.net/%7Evromero/8207320/webrev.00/jdk.dev.patch"
        moz-do-not-send="true">http://cr.openjdk.java.net/~vromero/8207320/webrev.00/jdk.dev.patch</a><br>
    </blockquote>
    <br>
  </body>
</html>