JEP 118 works with Lambda ?
forax at univ-mlv.fr
Thu Apr 17 08:00:14 UTC 2014
On 04/16/2014 09:54 PM, Brian Goetz wrote:
> The short answer is: the code being referred to (that synthesizes "map
> literals") has no claim to ever work. (And in fact, it does not work
> on the reference implementation, but I've heard tell it does "work"
> when compiled with ECJ.) And that it does not work is not a bug.
> Lambda expressions are expressions, not methods. There is no
> reflection on expressions. A lambda expression evaluates to an
> instance of a class implementing its target type. There is (by
> design) no guarantee what the name of that class is, whether that
> class is shared with that of other lambda expressions, or what the
> parameter names of its methods are.
> A compiler implementation may or may not choose to desugar lambda
> expressions to methods. If it does, it may or may not preserve the
> parameter names as they appear in source code. And if it does, this
> may freely change from day to day.
> To claim there is no "exception" for lambdas has it backwards; lambdas
> are not methods, and there is no way to reflect over them.
While I fully agree about the fact that the parameter names are not
available for lambda,
there is a special kind of lambda that is required by the spec to be
desugared to method by the compiler.
serializable lambda, a serializable lambda keep meta-data useful to
re-create itself and
the format of the serialization is fully specified by the spec .
Because the documentation of SerializedLambda explicitly refers to an
a serializable lambda must have an underlying method.
> On 4/16/2014 2:59 PM, Alex Buckley wrote:
>> // Adding compiler-dev
>> Since lambda expressions are expressions, they cannot be reflected over
>> directly. However, if you know the method that a lambda expression is
>> compiled to, then you can obviously call getParameters() on the
>> java.lang.reflect.Method object.
>> That said, even if you compiled with -parameters, there are bugs in the
>> name generation for parameters of the method, so Parameter.getName()
>> doesn't work. This has been discussed on compiler-dev and is being fixed
>> for JDK 8u20.
>> On 4/16/2014 11:43 AM, Luan Cestari wrote:
>>> Hi, Good morning/afternoon/evening! =)
>>> I got this email from a reply of help at openjdk.java.net ( from
>>> https://bugs.openjdk.java.net/secure/Dashboard.jspa , where I was
>>> to create an issue (maybe for enhance or bug, not really sure).
>>> I got a problem during a test using the getName from Parameter (from
>>> 118, new in Java 8) with Lambda expression (also new in Java 8). I
>>> made a
>>> simple class to reproduce the issue which I posted here
>>> https://gist.github.com/luan-cestari/10902418 , where the getName works
>>> fine using other classes like in this other code I made
>>> https://gist.github.com/luan-cestari/10902332. I started to investigate
>>> that after I saw a gist ( https://gist.github.com/galdosd/10823529,
>>> also created a discussion on
>>> saying that feature worked fine for him, so I talked with some guys in
>>> IRC ( OFTC#openjdk ), but we wasn't sure if it is a bug or not.
>>> I searched a bit and I found the following:
>>> - In http://openjdk.java.net/jeps/118 , it doesnt say about any
>>> exception around the Lambda functions
>>> - In Oracle documentation it mentions the JVM parameter that have
>>> to be
>>> used during the compilation to that work fine
>>> - In javadoc there is no more details about that (I think it could
>>> more clear that there is a JVM parameter or maybe it is possible
>>> to have
>>> this kind of parameter. Also it could say about execptions such as
>>> - I also saw a mail list (
>>> where Remi and Brian exchanged some mails where he said it is had the
>>> 118 due there are people that want thing in a way and people who
>>> want some changes
>>> - In that mail, they cited this document
>>> http://cr.openjdk.java.net/~abuckley/8misc.pdf which I think that
>>> parts of it are in JVM spec (
>>> - http://docs.oracle.com/javase/specs/ like
>>> http://docs.oracle.com/javase/specs/jvms/se8/jvms8.pdf and
>>> - ) but it just say the class structure in bytecode, nothing about
>>> Lambda and JEP 118
>>> As far as I know, Lambda will create some symbolic invocation using
>>> invokedynamic which is different than creating anonymous classes, so
>>> might be the root cause of the issue. But maybe there is some
>>> difference in
>>> the native implementations (for example, in my case I'm using Fedora 20
>>> with OpenJDK Runtime Environment (build 1.8.0-b132) / OpenJDK 64-Bit
>>> VM (build 25.0-b70, mixed mode)). In the IRC, people said that maybe
>>> IDE was generating the inner classes to make it work, but that would
>>> make a
>>> problem during the runtime if a different tool (like maven) compiles
>>> In summary, is the right behavior for JEP 118 return argx due lambda
>>> expressions? Maybe we could enhance it to make some new features (for
>>> 9 ).
>>> Thank you in advance,
>>> Kindest regards,
>>> Luan Cestari
>>> "All the gold which is under or upon the earth is not enough to give in
>>> exchange for virtue."
>>> "At his best, man is the noblest of all animals; separated from law and
>>> justice he is the worst."
>>> "A true friend is one soul in two bodies."
>>> "The only limit to your impact is your imagination and commitment."
>>> Tony Robbins
More information about the compiler-dev