Gunnar Morling created FLINK-30454:
--------------------------------------
Summary: Inconsistent class hierarchy in TaskIOMetricGroup
Key: FLINK-30454
URL: https://issues.apache.org/jira/browse/FLINK-30454
Project: Flink
Issue Type: Improvement
Components: Runtime / Metrics
Reporter: Gunnar Morling
I noticed an interesting issue when trying to compile the flink-runtime module
with Eclipse (same for VSCode): the _private_ inner class
{{org.apache.flink.runtime.metrics.groups.TaskIOMetricGroup.SizeGauge}} has yet
another _public_ inner class, {{SizeSupplier}}. The public method
{{org.apache.flink.runtime.metrics.groups.TaskIOMetricGroup.registerMailboxSizeSupplier(SizeSupplier<Integer>)}}
has a parameter of that type. The invocation of this method in
{{org.apache.flink.streaming.runtime.tasks.StreamTask.StreamTask(Environment,
TimerService, UncaughtExceptionHandler, StreamTaskActionExecutor,
TaskMailbox)}} can be compiled with the javac compiler of the JDK but fails to
compile with ecj:
{code}
The type TaskIOMetricGroup.SizeGauge from the descriptor computed for the
target context is not visible here.
{code}
I tend to believe that the behavior of Eclipse's compiler is the correct one.
After all, you couldn't explicitly reference the {{SizeSupplier}} type either.
One possible fix would be to promote {{SizeSupplier}} to the same level as
{{SizeGauge}}. This would be source-compatible but not binary-compatible,
though. I.e. code compiled against the earlier signature of
{{registerMailboxSizeSupplier()}} would be broken with a {{NoSuchMethodError}}.
Depending on whether {{registerMailboxSizeSupplier()}} are expected in client
code or not, this may or may not be acceptable. Another fix would be to make
{{SizeGauge}} public. I think that's the change I'd do. Curious what other
folks here think.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
