[ https://issues.apache.org/jira/browse/FLINK-5964?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Flink Jira Bot updated FLINK-5964: ---------------------------------- Labels: stale-minor (was: ) > Change TypeSerializers to allow construction of immutable types > --------------------------------------------------------------- > > Key: FLINK-5964 > URL: https://issues.apache.org/jira/browse/FLINK-5964 > Project: Flink > Issue Type: Improvement > Components: API / Type Serialization System > Affects Versions: 1.1.4, 2.0.0 > Reporter: Jayson Minard > Priority: Minor > Labels: stale-minor > > If your programming language has a lot of Immutable types (and with no > default constructor) Flink forces you to create new versions as read/write > POJO otherwise the types are rejected by the system. In Kotlin for example, > given a class and property values we can determine which constructor to call > and invoke it using knowledge of default values, nullable types and which > properties can be set in construction or after construction. > Flink provides no opportunity to use this model because Serializers are > littered with calls to `createInstance` that are not passed any values so > have no opportunity to fully inflate the object on construction. > This means that when you use Flink you throw away maybe hundreds of state > objects (my worst case) and have to create Flink-only variations which > becomes grunt work that adds no value. > Currently TypeExtractor isn't extendable, and all of the special cases are > hard coded. It should be configured the order of checking for type > information so that pluggable types can be added into the chain of analysis. > For example before `analyzePojo` is called I could special case a Kotlin > class returning a different TypeInformation instance. But I don't think that > solves the whole problem since other TypeSerializers make assumptions and > call `createInstance` on other TypeSerializers without knowing how they would > want to do the construction (in the Kotlin case it would be "tell me to > construct my instance and give me the list of named fields and serializers to > get their values and let me decide what to do). > What is the best idea for this change? With guidance, I can work on the PR. -- This message was sent by Atlassian Jira (v8.3.4#803005)