You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@flink.apache.org by "Till Rohrmann (JIRA)" <ji...@apache.org> on 2016/03/30 15:07:25 UTC
[jira] [Created] (FLINK-3681) CEP library does not support Java 8
lambdas as select function
Till Rohrmann created FLINK-3681:
------------------------------------
Summary: CEP library does not support Java 8 lambdas as select function
Key: FLINK-3681
URL: https://issues.apache.org/jira/browse/FLINK-3681
Project: Flink
Issue Type: Bug
Components: CEP
Affects Versions: 1.0.0
Reporter: Till Rohrmann
Assignee: Till Rohrmann
Priority: Minor
Fix For: 1.0.1
Currently, the CEP library does not support Java 8 lambdas to be used as {{select}} or {{flatSelect}} function. The problem is that the {{TypeExtractor}} has different semantics when calling {{TypeExtractor.getUnaryOperatorReturnType}} either with a Java 8 lambda or an instance of an UDF function.
To illustrate the problem assume we have the following UDF function
{code}
public interface MyFunction[T, O] {
O foobar(Map<String, T> inputElements);
}
{code}
When calling the {{TypeExtractor}} with an anonymous class which implements this interface, the first type parameter is considered being the input type of the function, namely {{T}}.
In contrast, when providing a Java 8 lambda for this interface, the {{TypeExtractor}} will see an input type of {{Map<String, T>}}.
This problem also occurs with a {{FlatMapFunction}} whose first type argument is {{T}} but whose first parameter of a Java 8 lambda is {{Iterable<T>}}. In order to solve the problem here, the {{TypeExtractor.getUnaryOperatorReturnType}} method has the parameters {{hasIterable}} and {{hasCollector}}. If these values are {{true}}, then a special code path is taken (in case of a Java 8 lambda), where the input type is compared to the first type argument of the first input parameter of the lambda (here an {{Iterable<T>}}). This hand-knitted solution does not generalize well, as it will fail for all parameterized types which have the input type at a different position (e.g. {{Map<String, T>}}.
In order to solve the problem, I propose to generalize the {{getUnaryOperatorReturnType}} a little bit so that one can specify at which position the input type is specified by a parameterized type.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)