flink-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Till Rohrmann (JIRA)" <j...@apache.org>
Subject [jira] [Created] (FLINK-3681) CEP library does not support Java 8 lambdas as select function
Date Wed, 30 Mar 2016 13:07:25 GMT
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 

public interface MyFunction[T, O] {
    O foobar(Map<String, T> inputElements);

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

This message was sent by Atlassian JIRA

View raw message