Details
-
Bug
-
Status: Closed
-
Minor
-
Resolution: Fixed
-
1.0.0
-
None
Description
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 type.