[jira] [Updated] (FLINK-10296) TypeExtractor only validates/matches exact POJO classes

["Robert Metzger (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/FLINK-10296?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Robert Metzger updated FLINK-10296:
-----------------------------------
    Component/s:     (was: Core)
                 API / Type Serialization System

> 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
>         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)