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

[Remi Forax]

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