Introduce a compiler option to store generic type information about a lambda expression using the Signature Attribute

[Stephan Ewen]

If I understand things correctly (please help me if I am wrong, I am not a
deep expert in this field) the main concern is:

Is it a good idea (or later possible at all) to grab a reference at all to
the synthetic method generated for the lambda, since the implementation of
proxies/factories may be subject to change. Plus there are corner cases,
where bridge methods are necessary. So that is a valid concern for the way
that some projects currently attempt reflection.

But is adding a generic signature to the synthetic method not an
independent problem issues from that? For anyone that picks up a reference
to that method (from the lambda or in whatever other way), the generic
information would be available, which would greatly help.

Greetings,
Stephan


On Mon, Jan 19, 2015 at 7:29 AM, Remi Forax <forax at univ-mlv.fr> wrote:

>
> On 01/19/2015 04:18 PM, Joel Borggrén-Franck wrote:
>
>> On 19 jan 2015, at 16:01, Remi Forax <forax at univ-mlv.fr> wrote:
>>>
>>> On 01/19/2015 03:39 PM, Joel Borggrén-Franck wrote:
>>>
>>>> On 7 jan 2015, at 21:18, Alex Buckley <alex.buckley at oracle.com> wrote:
>>>>>
>>>>> On 1/7/2015 7:22 AM, Timo Walther wrote:
>>>>>
>>>>>> the Java Reflection API allows to access the generic signature of
>>>>>> methods through the java.lang.reflect.Method#getGenericReturnType()
>>>>>> method. However, this is not yet supported for Lambda expressions.
>>>>>>
>>>>>> Given the following classes:
>>>>>>
>>>>>> class Tuple2<F0,F1> {
>>>>>>    F0 field0;
>>>>>>    F1 field1;
>>>>>>
>>>>>>    public Tuple2(F0 f0, F1 f1) {
>>>>>>      this.field0 = f0;
>>>>>>      this.field1 = f1;
>>>>>>    }
>>>>>> }
>>>>>>
>>>>>> interface Map<IN, OUT> {
>>>>>>    OUT map(IN in);
>>>>>> }
>>>>>>
>>>>>> Currently, there is no solution that allows to get further type
>>>>>> information about expressions like:
>>>>>>
>>>>>> Map<String, Tuple2<String, Integer>> map = (str) -> new Tuple2<>(str,
>>>>>> 1);
>>>>>> System.out.println(getReturnType(map)) // can only print Tuple2 =>
>>>>>> information about the Tuple2's fields are always lost
>>>>>>
>>>>> map is a variable, so it doesn't have a return type.
>>>>>
>>>>> If map is a class variable or an instance variable, then
>>>>> Field#getGenericType should help.
>>>>>
>>>>> Expressions (including lambda expressions) aren't generally exposed
>>>>> through Core Reflection. If an expression (such as a lambda expression)
>>>>> happens to be implemented as a method, then relying on the [generic]
>>>>> signature of that method is dangerous since it may change from release to
>>>>> release.
>>>>>
>>>>>  One could argue that we should generate more attributes for synthetic
>>>> methods. We did for example add annotations to bridges [1]. While we do
>>>> want to it discourage depending on a specific translation strategy, I’m not
>>>> sure adding Signature will make more code break once/if we change
>>>> translation strategy.
>>>>
>>> The problem is not that adding a Signature will break, it's that these
>>> information will be not available
>>> anymore if we use a strategy based on one lambda proxy shared for
>>> several lambdas*
>>>
>> But isn’t this unrelated? I’m saying it might be reasonable to expect _a_
>> Signature for a generic method even if it is synthetic. To me it sounds
>> like that signature will be much less specific in your prototype, but it
>> can still exist?
>>
>
> err, sorry not clear,
> Yes, you're right, the signature will still exist but there will be no way
> at runtime to get a reference (in the generic sense) to the synthetic
> method. Because the link from a lambda proxy to the lambda implementation
> will be hidden.
>
>
>> cheers
>> /Joel
>>
>>
> cheers,
> Rémi
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20150124/0e31afbc/attachment.html>