You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@beam.apache.org by "Thomas Groh (JIRA)" <ji...@apache.org> on 2017/05/01 18:11:04 UTC
[jira] [Reopened] (BEAM-2021) Fix Java's Coder class hierarchy
[ https://issues.apache.org/jira/browse/BEAM-2021?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Thomas Groh reopened BEAM-2021:
-------------------------------
There's a bit more work I'd like to get done, mainly splitting the class hierarchy out away from "everything in the SDK is a structured coder".
> Fix Java's Coder class hierarchy
> --------------------------------
>
> Key: BEAM-2021
> URL: https://issues.apache.org/jira/browse/BEAM-2021
> Project: Beam
> Issue Type: Improvement
> Components: beam-model-runner-api, sdk-java-core
> Affects Versions: First stable release
> Reporter: Kenneth Knowles
> Assignee: Thomas Groh
> Fix For: First stable release
>
>
> This is thoroughly out of hand. In the runner API world, there are two paths:
> 1. URN plus component coders plus custom payload (in the form of component coders alongside an SdkFunctionSpec)
> 2. Custom coder (a single URN) and payload is serialized Java. I think this never has component coders.
> The other base classes have now been shown to be extraneous: they favor saving ~3 lines of boilerplate for rarely written code at the cost of readability. Instead they should just be dropped.
> The custom payload is an Any proto in the runner API. But tying the Coder interface to proto would be unfortunate from a design perspective and cannot be done anyhow due to dependency hell.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)