I think this originally comes from the fact that we need to match the input TypeInfo against the generic signature, for example to figure out what "T" means in a MapFunction<Tuple2<T, Long>, T>. That is the reason why Flink can support generic functions even though there is type erasure at runtime.
Much nice than nullable types is to use Option[Type] for a field that may be null. In Scala, the OptionTypeInfo adds a null/not-null byte, which is probably what your custom nullable type also does. By adding this for Java (with Java 8 options, or a custom option type) would solve that issue as well. It would also let us retain the benefit that non-nullable fields are efficiently serialized. On Mon, Nov 9, 2015 at 9:32 AM, Chesnay Schepler <ches...@apache.org> wrote: > On 09.11.2015 08:49, Aljoscha Krettek wrote: > >> In the case of the TupleTypeInfo subclass it only works because the >> equals method of TypleTypeInfo is used, IMHO. >> > I've overridden the equals method to check specifically for my > implementation and not TupleTypeInfo, implemented a different serializer > (and verified that it is used), and it still works. >
