[
https://issues.apache.org/jira/browse/FLINK-10296?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17321565#comment-17321565
]
Flink Jira Bot commented on FLINK-10296:
----------------------------------------
This issue and all of its Sub-Tasks have not been updated for 180 days. So, it
has been labeled "stale-minor". If you are still affected by this bug or are
still interested in this issue, please give an update and remove the label. In
7 days the issue will be closed automatically.
> TypeExtractor only validates/matches exact POJO classes
> -------------------------------------------------------
>
> Key: FLINK-10296
> URL: https://issues.apache.org/jira/browse/FLINK-10296
> Project: Flink
> Issue Type: Bug
> Components: API / Type Serialization System
> Affects Versions: 1.5.1, 1.6.0
> Reporter: James Morgan
> Priority: Minor
> Labels: stale-minor
> Attachments: PojoTest.java
>
>
> I have a workflow that processes a stream of objects that implement an
> interface. The primary implementation was not a POJO and worked fine.
> When I added an implementation that was a POJO, the workflow fails with
> an error of Input mismatch; namely our POJO does not match the interface.
> The exception is thrown in TypeExtractor#validateInfo when the type it
> checks is an instanceof PojoTypeInfo (line 1456). When the object is
> _not_ a POJO, it is GenericTypeInfo (line 1476) and passes this validation.
> The difference between these two handling blocks is the POJO test is
> testing that the typeInfo's type class is _the same as_ the class of the
> type desired by the next step in the workflow. The Generic block tests
> that the class of the type _is assignable from_ the typeInfo's type class.
> Attached is a JUnit5 test that illustrates the issue. The testPojo()
> test will fail as written and indicates the mismatch of FooPojo and Foo.
> I believe that changing the block for the PojoTypeInfo to act like the
> GenericTypeInfo block would fix this but I don't know if there is a
> specific reason to treat POJOs differently here. (For example, if the
> Foo array in the test is changed to FooPojo[], then there is a compile
> time argument mismatch: TestMapFunction cannot be converted to
> MapFunction<FooPojo,R>.)
> Workarounds:
> 1. Avoid POJOs when using interfaces as part of the steps of the workflow.
> 2. Modify the map function to be a generic class with T extends Foo:
> TestMapFunction<T extends Foo> implements MapFunction<T, String>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
