Please keep the discussion on the mailing list rather than commenting on the wiki (wiki discussions get unwieldy fast).
Motivation
It looks that currently the AbstractStreamOperator API has some scope/stability annotation inconsistency. More specifically,
- The AbstractStreamOperator class is marked as @PublicEvolving
- AbstractStreamOperator.getInternalTimerService() returns a type of InternalTimerService which is marked as @Internal
- InternalOperatorMetricGroup and InternalIOperatorIOMetricGroup are also available to the subclasses of AbstractStreamOperator but marked as @Internal
Although the naming pattern of "InternalXXX" is a little confusing even somewhat misleading, this FLIP tends to leave that as is and only fix the annotation inconsistency.
Public Interfaces
Change the scope annotation of the following classes from @Internal to @PublicEvolving.
- org.apache.flink.streaming.api.operators.InternalTimerService
- org.apache.flink.runtime.metrics.groups.InternalOperatorMetricGroup
- org.apache.flink.runtime.metrics.groups.InternalOperatorIOMetricGroup
Proposed Changes
Please see the public interface section.
Compatibility, Deprecation, and Migration Plan
The FLIP only changes the method changes are fully backwards compatible.
Test Plan
N/A
Rejected Alternatives
The following change would address both the annotation inconsistency and the misleading naming issues.
- Introduce a new @PublicEvolving class of NamespacedTimerService which extends from the InternalTimerService class.
- Deprecate the InternalTimerService class. From now on, no change should be made to this class.
- Add a new method of AbstractStreamOperator.getNamespacedTimerService() which returns a NamespacedTimerService.
- Mark AbstractStreamOperator.getInternalTimerService() as deprecated, and simply delegate the call to AbstractStreamOperator.getNamespacedTimerService().
This is a fully backwards compatible solution which replaces the class and method named in InernalXXX Pattern with new class and method.
The downside of this proposal is that we will have a few more deprecated methods / classes in Flink. Given that we don't know when the next major version bump will come, I'd prefer not introducing more deprecations unless necessary.