Thanks Junrui for driving this proposal! I believe this is helpful for the new Process Function API. Because we don't need to move some related class/components from flink-core to a pure API module (maybe, called flink-core-api) after this. Even though the FLIP related to new API is in preparation atm, I still want to emphasize our goal is that user application should no longer depend on these stuff. So I'm + 1 for this proposal.
Best regards, Weijie Zhu Zhu <reed...@gmail.com> 于2023年11月2日周四 16:00写道： > Thanks Junrui for creating the FLIP and kicking off this discussion. > > The community has been constantly striving to unify and simplify the > configuration layer of Flink. Some progress has already been made, > such as FLINK-29379. However, the compatibility of public interfaces > poses an obstacle to completing the task. The release of Flink 2.0 > presents a great opportunity to accomplish this goal. > > +1 for the proposal. > > Thanks, > Zhu > > Rui Fan <1996fan...@gmail.com> 于2023年11月2日周四 10:27写道： > > > Thanks Junrui for driving this proposal! > > > > ConfigOption is easy to use for flink users, easy to manage options > > for flink platform maintainers, and easy to maintain for flink developers > > and flink community. > > > > So big +1 for this proposal! > > > > Best, > > Rui > > > > On Thu, Nov 2, 2023 at 10:10 AM Junrui Lee <jrlee....@gmail.com> wrote: > > > > > Hi devs, > > > > > > I would like to start a discussion on FLIP-381: Deprecate configuration > > > getters/setters that return/set complex Java objects[1]. > > > > > > Currently, the job configuration in FLINK is spread out across > different > > > components, which leads to inconsistencies and confusion. To address > this > > > issue, it is necessary to migrate non-ConfigOption complex Java objects > > to > > > use ConfigOption and adopt a single Configuration object to host all > the > > > configuration. > > > However, there is a significant blocker in implementing this solution. > > > These complex Java objects in StreamExecutionEnvironment, > > CheckpointConfig, > > > and ExecutionConfig have already been exposed through the public API, > > > making it challenging to modify the existing implementation. > > > > > > Therefore, I propose to deprecate these Java objects and their > > > corresponding getter/setter interfaces, ultimately removing them in > > > FLINK-2.0. > > > > > > Your feedback and thoughts on this proposal are highly appreciated. > > > > > > Best regards, > > > Junrui Lee > > > > > > [1] > > > > > > https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=278464992 > > > > > >
