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

Stephan Ewen sewen at
Fri Jan 9 13:58:04 UTC 2015

I can add to that as a committer in the same project as Timo (Apache Flink):

We can fall back to other generic means in the case where we do not get
this generic type information. If we have that type information, we can
configure and code-generate custom tailored type utilities, which make
things much more efficient..

In addition, it makes things more convenient for the users of Apache Flink.
They currently have (in some cases) to hint generic types that were type


On Fri, Jan 9, 2015 at 2:27 PM, Timo Walther <twalthr at> wrote:

> 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 (
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the compiler-dev mailing list