Different serialization strategies for different formats?

Brian Goetz brian.goetz at oracle.com
Thu Jun 20 13:43:46 UTC 2019

Yes, a similar question came up in an internal discussion as well.  

> Consider we have a Color class which represents a color in RGB format:
> class Color { private final int rgb; }
> The most obvious and efficient way to serialize/deserialize its state is to extract this int field:
> It's great for binary serialization. However if I serialize to JSON I would not like to see `color: 16711680`. JSON or XML are intended to be at least partially human-readable. So probably I want to see `color: red` or at least `color: #FF0000`. Well no problem, we can alternatively serialize as string:

Good example.  There’s no problem in the model with multiple serializers, but it raises the question: how would a client select which form?  Suppose instead of (or in addition to) the version property on the annotation, we had some other selectors.  Suppose for sake of argument that Color has the following serializers:

    @Serializer(selector = “binary”)
    public pattern Color(int colorValue) { … }

    @Serializer(selector = “text”)
    public pattern Color(int r, int g, int b) { … }

These tags are selected by the author of Color at development time.  But the ultimate user of serialization is someone in some other maintenance domain, asking to serialize a whole graph that has colors in it.  Without some sort of global agreement on the taxonomy of selectors, a given graph might have many classes which reflect the text/binary distinction (just one possible distinction) in a dozen different ways.  And the tex/tbinary distinction might not be the only distinction one wants to reflect; one could imagine varying degrees of detail preservation, for example.  

So I like the idea of treating the set of serializers as something that can be queried over by a serialization library — the question is — what is the structure of these queries, such that would-be queriers don’t have to “join” 100 different “tables” each with their own schema style?

More information about the amber-spec-experts mailing list