[jira] [Commented] (FLINK-3681) CEP library does not support Java 8 lambdas as select function

["ASF GitHub Bot (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/FLINK-3681?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15217943#comment-15217943 ] 

ASF GitHub Bot commented on FLINK-3681:
---------------------------------------

GitHub user tillrohrmann opened a pull request:

    https://github.com/apache/flink/pull/1840

    [FLINK-3681] [cep, typeextractor] Generalize TypeExtractor to support more lambdas

    The TypeExtractor.getUnaryOperatorReturnType and TypeExtractor.getBinaryOperatorReturnType
    methods have been extended to support positional arguments for the input types. This allows
    to support parameterized types as Java 8 lambda arguments where the input type is not specified
    by the first type argument (e.g. Map<String, T>). This also solves the problem that the CEP
    library did not support Java 8 lambdas as select functions.

You can merge this pull request into a Git repository by running:

    $ git pull https://github.com/tillrohrmann/flink fixCEPJava8

Alternatively you can review and apply these changes as the patch at:

    https://github.com/apache/flink/pull/1840.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

    This closes #1840
    
----
commit 4e626b79e290acb7a5fd546a985310aef17db8c2
Author: Till Rohrmann <tr...@apache.org>
Date:   2016-03-30T12:55:27Z

    [FLINK-3681] [cep, typeextractor] Generalize TypeExtractor to support more lambdas
    
    The TypeExtractor.getUnaryOperatorReturnType and TypeExtractor.getBinaryOperatorReturnType
    methods have been extended to support positional arguments for the input types. This allows
    to support parameterized types as Java 8 lambda arguments where the input type is not specified
    by the first type argument (e.g. Map<String, T>). This also solves the problem that the CEP
    library did not support Java 8 lambdas as select functions.

----


> 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)