flink-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "ASF GitHub Bot (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (FLINK-3681) CEP library does not support Java 8 lambdas as select function
Date Wed, 30 Mar 2016 14:35:25 GMT

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

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

Github user uce commented on a diff in the pull request:

    https://github.com/apache/flink/pull/1840#discussion_r57898915
  
    --- Diff: flink-core/src/main/java/org/apache/flink/api/java/typeutils/TypeExtractor.java
---
    @@ -291,12 +347,15 @@ protected TypeExtractor() {
     				
     				// parameters must be accessed from behind, since JVM can add additional parameters
e.g. when using local variables inside lambda function
     				final int paramLen = m.getGenericParameterTypes().length - 1;
    -				final Type input = (hasCollector)? m.getGenericParameterTypes()[paramLen - 1] : m.getGenericParameterTypes()[paramLen];
    -				validateInputType((hasIterable)?removeGenericWrapper(input) : input, inType);
    +				final Type input = (outputTypeArgumentIndex >= 0) ? m.getGenericParameterTypes()[paramLen
- 1] : m.getGenericParameterTypes()[paramLen];
    +				validateInputType((inputTypeArgumentIndex >= 0) ? extractTypeArgument(input, inputTypeArgumentIndex)
: input, inType);
     				if(function instanceof ResultTypeQueryable) {
     					return ((ResultTypeQueryable<OUT>) function).getProducedType();
     				}
    -				return new TypeExtractor().privateCreateTypeInfo((hasCollector)? removeGenericWrapper(m.getGenericParameterTypes()[paramLen])
: m.getGenericReturnType(), inType, null);
    +				return new TypeExtractor().privateCreateTypeInfo((
    +					outputTypeArgumentIndex >= 0)? extractTypeArgument(m.getGenericParameterTypes()[paramLen],
outputTypeArgumentIndex) : m.getGenericReturnType(),
    --- End diff --
    
    Trivial:
    - line break after second `(` on purpose?
    - White space before `?` missing


> 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.1.0, 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)

Mime
View raw message