Thanks Junrui for driving this. Making configurations simple and consistent has great benefits for both users and devs. +1 for the proposal.
Best, Lijie weijie guo <guoweijieres...@gmail.com> 于2023年11月2日周四 16:49写道： > 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 > > > > > > > > > >
