Mailing-List: contact commits-help@beam.incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@beam.incubator.apache.org
Date: Mon, 4 Apr 2016 22:16:25 +0000 (UTC)
From: "Kenneth Knowles (JIRA)" <jira@apache.org>
To: commits@beam.incubator.apache.org
Message-ID: <JIRA.12955956.1459808151000.131524.1459808185460@Atlassian.JIRA>
In-Reply-To: <JIRA.12955956.1459808151000@Atlassian.JIRA>
References: <JIRA.12955956.1459808151000@Atlassian.JIRA>
 <JIRA.12955956.1459808151055@arcas>
Subject: [jira] [Created] (BEAM-169) Need serialized form and
 serialVersionUID for user-facing superclasses
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit

Kenneth Knowles created BEAM-169:
------------------------------------

             Summary: 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


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
(v6.3.4#6332)