Different serialization strategies for different formats?

[Remi Forax]

----- Mail original -----
> De: "Brian Goetz" <brian.goetz at oracle.com>
> À: "Tagir Valeev" <amaembo at gmail.com>
> Cc: "amber-spec-experts" <amber-spec-experts at openjdk.java.net>
> Envoyé: Jeudi 20 Juin 2019 15:43:46
> Objet: Re: Different serialization strategies for different formats?

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

I don't think we should specify a query scheme, it seems more future proof to only provide a way to expose all serializers (resp deserializer) and let the serialization library provides their own annotations / do the selection on top of what we expose.

so the JDK will only provide @Serializer/@Deserializer and an hypothetical JSON library will provide @JsonFormat to indicate a supplementary way of selection

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

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


Rémi