[
https://issues.apache.org/jira/browse/BEAM-169?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17545964#comment-17545964
]
Danny McCormick commented on BEAM-169:
--------------------------------------
This isn't actually real, but this issue has been migrated to
https://github.com/apache/beam/issues/17871
> Need serialized form and serialVersionUID for user-facing superclasses
> ----------------------------------------------------------------------
>
> Key: BEAM-169
> URL: https://issues.apache.org/jira/browse/BEAM-169
> Project: Beam
> Issue Type: Bug
> Components: sdk-java-core
> Reporter: Kenneth Knowles
> Priority: P3
> Labels: Clarified, serialization
>
> When a class does not have an explicit {{serialVersionUID}}, it should be
> considered an unstable value based on the exact version of the code. This is
> fine for transmission most of the time, but never acceptable for persistence
> where backwards compatibility matters.
> There are two use cases that require explicit serialized form and
> {{serialVersionUID}} even just for transmission. They are required for
> user-facing superclasses such as DoFn, WindowFn, etc, to support the
> following:
> # Encoding a pipeline with a JDK and decoding with a JDK that computes
> defaults differently.
> # Encoding a pipeline against a version of the Beam SDK and decoding with a
> different version.
> The first situation should be rare since there is a deterministic spec, but
> we have unfortunately seen it.
> The second situation is very reasonable; a runner might want to run with
> additional security fixes in the SDK, etc. Given a correct semantic version
> for the SDK, the pipeline author and runner author may reasonably expect it
> to work.
> So we should add explicit serialization to superclasses that are necessarily
> encoded as part of a user's pipeline.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
