Hi devs, FLINK-14096[1] was created yesterday. It is aimed at merge the bridge class NewClusterClient into ClusterClient because with the effort under FLINK-10392 this bridge class is no longer necessary.
Technically in current codebase all implementation of interface NewClusterClient is subclass of ClusterClient so that the work required is no more than move method declaration. It helps we use type signature ClusterClient instead of <ClusterClient & NewClusterClient or even cannot represent the latter if we aren't in a type variable context. This should not affect anything internal in Flink scope. However, as mentioned by Kostas in the JIRA and a previous discussion under a commit[2], it seems that we provide some levels of backward compatibility for ClusterClient and thus it's better to start a public discussion here. There are two concerns from my side. 1. How much impact this proposal brings to users programming directly to ClusterClient? The specific changes here are add two methods `submitJob` and `requestJobResult` which are already implemented by RestClusterClient and MiniClusterClient. Users would only be affected if they create a class that inherits ClusterClient and doesn't implement these methods. Besides, users who create a class that implements NewClusterClient would be affected by the removal of NewClusterClient. If we have to provide backward compatibility and the impact is no further than those above, we can deprecate NewClusterClient, merge the methods into ClusterClient with a dummy default like throw Exception. 2. Why do we provide backward compatibility for ClusterClient? It already surprises Kostas and me while we think ClusterClient is a totally internal class which we can evolve regardless of api stability. Our community promises api stability by marking class and/or method as @Public/@PublicEvolving. It is wried and even dangerous we are somehow enforced to provide backward compatibility for classes without any annotation. Besides, as I mention in [2], users who anyway want to program directly to internal classes/interfaces are considered to prepare to make adaptations when bump version of Flink. Best, tison. [1] https://issues.apache.org/jira/browse/FLINK-14096 [2] https://github.com/apache/flink/commit/dc9e4494dddfed36432e6bbf6cd3231530bc2e01
