<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <div class="moz-cite-prefix">Hi all,<br>
      <br>
      Please review this public review for bug [1] which can be found at
      [2].<br>
      <br>
      Some background:<br>
      <br>
      This bug was originally reported on the type-annotations-dev list.
      A code like this one:<br>
      <div class="code panel" style="border-width: 1px;">
        <div class="codeContent panelContent">
          <pre class="code-java"><span class="code-keyword">import</span> java.lang.annotation.*;
<span class="code-keyword">import</span> java.util.function.*;

@Retention(RetentionPolicy.RUNTIME)
@Target(ElementType.TYPE_USE)
@<span class="code-keyword">interface</span> TA {}

class LambdaFormal {
   IntUnaryOperator x = (@TA <span class="code-object">int</span> y) -&gt; 1;
}
</pre>
        </div>
      </div>
      <br>
      is producing a NPE in javac. Type annotations code assumes that
      any lambda expression will always have a method as it's owner,
      which is not always true. <br>
      Nevertheless this approach can be considered correct because the
      compiler is creating a method symbol in cases where a method is
      not present, field declarations.<br>
      <br>
      LambdaToMethod code was also expecting type annotations in one
      method, in the case of instance fields, in the first constructor,
      in the case of static fields in a fake &lt;clinit&gt; method. <br>
      <br>
      What I have done here is to sync Attr with LTM so they use the
      same method depending on the particular case, see also the
      comments added in the patch. <br>
      As a side result the method used by Attr and LTM classes is also
      used as a holder for type annotations, thus solving the current
      bug.<br>
      <br>
      Probably this is not the ultimate solution to the problem. It
      should be studied if both type annotations and lambda code can be
      made more flexible such that they don't assume that lambda
      expressions have a method as it's owner, but I think that this is
      a good solution for now.<br>
      <br>
      Thanks in advance for any comments,<br>
      <br>
      Vicente<br>
      <br>
      [1] <a class="moz-txt-link-freetext" href="https://bugs.openjdk.java.net/browse/JDK-8029721">https://bugs.openjdk.java.net/browse/JDK-8029721</a><br>
      [2] <a class="moz-txt-link-freetext" href="http://cr.openjdk.java.net/~vromero/8029721/webrev_01/">http://cr.openjdk.java.net/~vromero/8029721/webrev_01/</a><br>
      <br>
      On 10/12/13 19:55, Vicente-Arturo Romero-Zaldivar wrote:<br>
    </div>
    <blockquote cite="mid:52A771A9.3090809@oracle.com" type="cite">On
      10/12/13 18:36, Werner Dietl wrote:
      <br>
      <blockquote type="cite">&gt;From Vicente's description I took away
        that the problem is too
        <br>
        fundamental for me to work around in type-annotations.
        <br>
      </blockquote>
      <br>
      Hi Werner,
      <br>
      <br>
      I will submit a public webrev shortly.
      <br>
      <br>
      <blockquote type="cite">
        <br>
        Can we get the, admittedly ugly, hack I have in type-annotations
        into
        <br>
        tl? It at least prevents this particular crash.
        <br>
        I updated type-annotations/langtools to make diffing easier.
        <br>
      </blockquote>
      <br>
      I should push the patch by the end of this week so the crash
      should be fixed.
      <br>
      <br>
      Thanks,
      <br>
      Vicente
      <br>
      <br>
      <blockquote type="cite">
        <br>
        It is a pity that this means that the compiler is not generating
        correct
        <br>
        bytecode for type annotations within lambdas within field
        initializers.
        <br>
        <br>
        cu, WMD.
        <br>
        <br>
        On 13-12-10 01:23 PM, Alex Buckley wrote:
        <br>
        <blockquote type="cite">On 12/8/2013 3:36 PM, Vicente-Arturo
          Romero-Zaldivar wrote:
          <br>
          <blockquote type="cite">I have created this bug entry to track
            this issue:
            <br>
            <a class="moz-txt-link-freetext" href="https://bugs.openjdk.java.net/browse/JDK-8029787">https://bugs.openjdk.java.net/browse/JDK-8029787</a>
            <br>
            <br>
            I think this should be deferred for now, but Alex if you
            think that this
            <br>
            should be fixed asap feel free to raise the priority to P2
            and provide a
            <br>
            justification.
            <br>
          </blockquote>
          Vicente, thanks for looking at the issue. I see that
          JDK-8029787 is now
          <br>
          closed as a duplicate of JDK-8029721, which is itself a P2.
          <br>
          <br>
          Werner, FYI, we (Oracle) are now only working on P2s and P1s
          for JDK 8,
          <br>
          and all P2s must be resolved by 12/13. After 12/13, it's P1s
          only;
          <br>
          everything else gets deferred to an update release or JDK 9.
          <br>
          <br>
          Alex
          <br>
        </blockquote>
      </blockquote>
      <br>
    </blockquote>
    <br>
  </body>
</html>