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)

Reply via email to