[FLINK-11409] Make `ProcessFunction`, `ProcessWindowFunction` and etc. pure interfaces

• Type: Improvement
• Status: Open
• Priority: Minor
• Resolution: Unresolved
• Fix Version/s: 2.0.0
• Component/s: API / DataStream
• Labels: Breaking-Change auto-deprioritized-major auto-unassigned
• Flags: Important
• Assignee: Unassigned
• Reporter: Kezhu Wang
• Created: 22/Jan/19 18:23
• Updated: 30/Jun/21 22:38

Description

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
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.