JEP 118 works with Lambda ?

Remi Forax forax at
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 [1].
Because the documentation of SerializedLambda explicitly refers to an 
implementation method,
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.
>> Alex
>> 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 ( from
>>> , where I was
>>> thinking
>>> 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 
>>> JEP
>>> 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
>>> , where the getName works
>>> fine using other classes like in this other code I made
>>> I started to investigate
>>> that after I saw a gist (, 
>>> which
>>> 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 , 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
>>> make
>>>     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
>>> Lambda
>>>     expressions)
>>>     - I also saw a mail list (
>>> where Remi and Brian exchanged some mails where he said it is had the
>>> JEP
>>>     118 due there are people that want thing in a way and people who
>>> doesn't
>>>     want some changes
>>>     - In that mail, they cited this document
>>> which I think that
>>> some
>>>     parts of it are in JVM spec (
>>>     - like
>>> 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 
>>> this
>>> 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
>>> Server
>>> VM (build 25.0-b70, mixed mode)). In the IRC, people said that maybe 
>>> the
>>> 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 
>>> the
>>> project.
>>> 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
>>> Java
>>> 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."
>>> Plato
>>> "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."
>>> Aristotle
>>> "The only limit to your impact is your imagination and commitment."
>>> Tony Robbins

More information about the compiler-dev mailing list