Github user StephanEwen commented on the issue: https://github.com/apache/flink/pull/4943 I updated this PR with the following proposed solution: 1. Avro is always part of the user code space, and hence will be loaded into the user code classloader. This solves multiple problems: - It allows users to use a different Avro version compared to the version in a spoiled classpath (for example when Hadoop depenencies pull in another Avro version). - It means that Avro class and schema caching is done per user code classloader, not JVM wide. That prevents "X cannot be cast to X" exceptions. 2. By default, a new pure Avro serializer is used for Avro types (in flight and in state). Since Avro class format changed, having compatibility activated by default is not possible anyways. 3. If a user wants to recover an old savepoint that happend to have Avro types serialized as PoJos, they need to do the following; - Set the Avro version to the same version that they had when creating the savepoint. Since Avro now lives in user code space, that is possible without changing/rebuilding Flink. - Pass a Flag to the `AvroTypeInfo` to use a backwards compatible Serializer: `new AvroTypeInfo(myType, true)`.
---