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