Introduce a compiler option to store generic type information about a lambda expression using the Signature Attribute
Timo Walther
twalthr at apache.org
Fri Jan 9 13:27:08 UTC 2015
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
More information about the compiler-dev
mailing list