<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) -> 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 <clinit> 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">>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>