You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@beam.apache.org by "Luke Cwik (JIRA)" <ji...@apache.org> on 2017/04/20 16:15:04 UTC

[jira] [Commented] (BEAM-2021) Fix Java's Coder class hierarchy

    [ https://issues.apache.org/jira/browse/BEAM-2021?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15976987#comment-15976987 ] 

Luke Cwik commented on BEAM-2021:
---------------------------------

We can just use Java serialization for all CustomCoder payloads and we can use AutoService/ServiceLoader to bind converters for well known types dynamically. This way the proto dependency stuff can be shaded away and is never part of the Coder type and only people defining well known types ever need to deal with a converter.

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