[jira] [Updated] (FLINK-11409) Make `ProcessFunction`, `ProcessWindowFunction` and etc. pure interfaces

["Flink Jira Bot (Jira)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/FLINK-11409?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Flink Jira Bot updated FLINK-11409:
-----------------------------------
    Labels: Breaking-Change auto-unassigned stale-major  (was: Breaking-Change auto-unassigned)

I am the [Flink Jira Bot|https://github.com/apache/flink-jira-bot/] and I help the community manage its development. I see this issues has been marked as Major but is unassigned and neither itself nor its Sub-Tasks have been updated for 30 days. I have gone ahead and added a "stale-major" to the issue". If this ticket is a Major, please either assign yourself or give an update. Afterwards, please remove the label or in 7 days the issue will be deprioritized.


> Make `ProcessFunction`, `ProcessWindowFunction` and etc. pure interfaces
> ------------------------------------------------------------------------
>
>                 Key: FLINK-11409
>                 URL: https://issues.apache.org/jira/browse/FLINK-11409
>             Project: Flink
>          Issue Type: Improvement
>          Components: API / DataStream
>            Reporter: Kezhu Wang
>            Priority: Major
>              Labels: Breaking-Change, auto-unassigned, stale-major
>             Fix For: 2.0.0
>
>
> I found these functions express no opinionated demands from implementing classes. It would be nice to implement as interfaces not abstract classes as abstract class is intrusive and hampers caller user cases. For example, client can't write an `AbstractFlinkRichFunction` to unify lifecycle management for all data processing functions in easy way.
> I dive history of some of these functions, and find that some functions were converted as abstract class from interface due to default method implementation, such as `ProcessFunction` and `CoProcessFunction` were converted to abstract classes in FLINK-4460 which predate -FLINK-7242-. After -FLINK-7242-, [Java 8 default method|https://docs.oracle.com/javase/tutorial/java/IandI/defaultmethods.html]
>  would be a better solution.
> I notice also that some functions which are introduced after -FLINK-7242-, such as `ProcessJoinFunction`, are implemented as abstract classes. I think it would be better to establish a well-known principle to guide both api authors and callers of data processing functions.
> Personally, I prefer interface for all exported function callbacks for the reason I express in first paragraph.
> Besides this, with `AbstractRichFunction` and interfaces for data processing functions I think lots of rich data processing functions can be eliminated as they are plain classes extending `AbstractRichFunction` and implementing data processing interfaces, clients can write this in one line code with clear intention of both data processing and lifecycle management.
> Following is a possible incomplete list of data processing functions implemented as abstract classes currently:
>  * `ProcessFunction`, `KeyedProcessFunction`, `CoProcessFunction` and `ProcessJoinFunction`
>  * `ProcessWindowFunction` and `ProcessAllWindowFunction`
>  * `BaseBroadcastProcessFunction`, `BroadcastProcessFunction` and `KeyedBroadcastProcessFunction`
> All above functions are annotated with `@PublicEvolving`, making they interfaces won't break Flink's compatibility guarantee but compatibility is still a big consideration to evaluate this proposal.
> Any thoughts on this proposal ? Please must comment out.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)