James Morgan created FLINK-10296:
------------------------------------
Summary: 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: Core
Affects Versions: 1.6.0, 1.5.1
Reporter: James Morgan
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
(v7.6.3#76005)
