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.