You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@flink.apache.org by "Gunnar Morling (Jira)" <ji...@apache.org> on 2022/12/19 14:18:00 UTC
[jira] [Updated] (FLINK-30454) Inconsistent class hierarchy in TaskIOMetricGroup
[ https://issues.apache.org/jira/browse/FLINK-30454?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Gunnar Morling updated FLINK-30454:
-----------------------------------
Description:
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:java}
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.
was:
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.
> 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
> Priority: Major
>
> 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:java}
> 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)