[ https://issues.apache.org/jira/browse/FLINK-6114?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15932576#comment-15932576 ]
Greg Hogan commented on FLINK-6114: ----------------------------------- [~lukehutch] Flink most certainly allows {{groupBy}}s and {{join}}s on generic fields, for example any of the Gelly algorithms in {{org.apache.flink.graph.library}}. The Flink type system must deduce the type of all fields in order to create the serializer. Types are defined on sources then tracked through each operation. If a type cannot be deduced from inputs and outputs then it must be explicitly defined. We can look at this if you are able to post more code. > Type checking fails with generics, even when concrete type of field is not > needed > --------------------------------------------------------------------------------- > > Key: FLINK-6114 > URL: https://issues.apache.org/jira/browse/FLINK-6114 > Project: Flink > Issue Type: Bug > Components: Core > Affects Versions: 1.2.0 > Reporter: Luke Hutchison > > The Flink type checker does not allow generic types to be used in any field > of a tuple when a join is being executed, even if the generic is not in a > field that is involved in the join. > I have a type Tuple3<String, K, Float>, which contains a generic type > parameter K. I am joining using .where(0).equalTo(0). The type of field 0 is > well-defined as String. However, this gives me the following error: > {noformat} > Exception in thread "main" > org.apache.flink.api.common.functions.InvalidTypesException: Type of > TypeVariable 'K' in 'public static org.apache.flink.api.java.DataSet > mypkg.MyClass.method(params)' could not be determined. This is most likely a > type erasure problem. The type extraction currently supports types with > generic variables only in cases where all variables in the return type can be > deduced from the input type(s). > at > org.apache.flink.api.java.typeutils.TypeExtractor.createSubTypesInfo(TypeExtractor.java:989) > {noformat} > The code compiles fine, however -- the static type system is able to > correctly resolve the types in the surrounding code. > Really only the fields that are affected by joins (or groupBy, aggregation > etc.) should be checked for concrete types in this way. -- This message was sent by Atlassian JIRA (v6.3.15#6346)