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

[Timo Walther]

Yes, you are right. It can be dangerous if not implemented safely and it 
is a pretty hacky solution, we are aware of that.

However, in Flink we stick to the paradigm "Write like a programming 
language, execute like a database", the more type information we have 
the efficient the program can be execute.
But this is quite difficult if type information is missing.

In programs like

stringData
.flatMap((String s, Collector<String> out) -> out.collect(s) )
.writeToFile("xyz");

we have currently no chance to determine the type of the collector after 
erasure and have to treat it as "Object". This makes Lambda expression 
inefficient in many use cases.

Other hacks that use e.g. the constant pool 
(https://github.com/jhalterman/typetools) do also not support generic 
lambda arguments.

So a compiler option would make many people happy.

Regards,
Timo

On 07.01.2015 21:18, Alex Buckley 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.
>
> Alex