More granular control of class discriminator at use site

[geoffliu]

What is your use-case and why do you need this feature?

Suppose we have sealed interface with subclasses to model two special kinds of products:

interface Product
data class FooProduct(...): Product
data class BarProduct(...): Product

And requests that get one of the base types:

data class GetFooProductResponse(
  ... other fields
  product: FooProduct
)

Once this response is serialized to the front end, the FooProduct objects do not have class discriminator. I understand this is documented behavior, but the workarounds are all a bit uncomfortable:

• Front end attaches class discriminator when it receives the response, but this is error prone
• Change FooProduct to just Product in the response, but we lose type safety and intentionality
• ClassDiscriminatorMode is a non-starter. I'm in a Spring project, response serialization settings are global, turning it on would affect everything else in the project

I think my realistic options are the following, unless I missed something:

• Add a @Serializable(with = FooProductSerializer) on the products field, and it forwards all calls to a serializer<Product>()
• Hook into Spring response serialization and add special case

Describe the solution you'd like

Ideally, more granular control of class discriminator, so something like

@ClassDiscriminatorMode(ALWAYS) data class FooProduct(...)

Or

@ClassDiscriminatorMode(ALL_SEALED_SUBCLASSES) interface Product

Or 

data class GetFooProductResponse(
  ... other fields
  @ClassDiscriminatorMode(ALWAYS)
  product: FooProduct
)

Short of that, if the @Serializable annotation can accept another class

data class GetFooProductResponse(
  ... other fields
  @Serializable(as = Product::class)
  product: FooProduct
)

I realize there could be some ambiguity with ClassDiscriminatorMode as a field annotation approach, as whether it's recursive or not, what happens with List<FooProduct>, etc, but annotation on class would be pretty clean? In any case, curious what people think, also curious if I'm just missing something obvious.

[pdvrieze]

Some sort of annotation makes a lot of sense. I'd be in favour of a format independent annotation. Such an annotation would indicate to the format that the type/attribute would need to be serialized as if it were polymorphic, but actually being a concrete (leaf) type (like a sealed base class with only a single child that happens to be itself).

In principle having annotations on types would be a good solution. Annotations on parent types would make some sense but also have challenges:

• Annotations on parent types are not visible in the source code of the child, and this may not be a good developer experience
• Annotation inheritance for serialization would need to be supported by the plugin. ClassDiscriminatorMode is a (Json) format specific annotation, so a mechanism (meta-annotation) would need to be created to allow for (serialInfo) annotations to indicate that they should be inherited.
• We should also note that even if we want to force "copied" annotations the annotations for which this is required still need to be identified somehow (and some code needs to check it - e.g. the plugin).

The context where this plays is where a child that could be used in polymorphic context is used as concrete type instead. In such context the format does not know that the child could also be polymorphic. Of course there can also be future/backward compatibility reasons to make a concrete type child work as polymorphic type.

In the case of web frameworks, this often comes about due to serialization either being resolved dynamically in some part of the serialization path rather than the static type being used, or accidental use of the wrong serializer (in reified inline helper functions).

Btw. what happens if you put @Polymorphic on your field - that should trigger the polymorphic code path (but may need a serializersModule)

[geoffliu]

Yeah, we've run into this once before because of a type erasure, and serializer being resolved dynamically. We were able to work around it that time.

Sad to report, adding @Polymorphic has no discernible effect. I did not need to register module either. I'm guessing it's ignored if static resolution works?

[sandwwraith]

Yup, annotation to specify ClassDiscriminatorMode seems to be the way

[pdvrieze]

@sandwwraith One thing on the annotation. The name needs to be somewhat carefully thought out as there are two "modes":

• Whether or not discriminators should be written with variants: (never, default, force-default, object),
• Format specific information on how discriminators should be written

On the variants, I'm thinking the following (the names are just the first thing that comes to mind):

• never: A discriminator is never written for this element (if valid for the format)
• default: The behaviour from the context (ultimately from the format configuration, but possibly changed by a members declaration.
• force-default: The behaviour is that specified in the format configuration (a reset if you will), only relevant if any tree ancestor has members=true
• object: The discriminator is always written for this object (where valid, otherwise ignored). The option "Always" would capture primitives, lists, etc. which cannot be polymorphic.

Unfortunately a value of "IF_POLYMORPHIC" that would trigger if a value could be used polymorphically would not work

Then there would be a second "members" parameter to the annotation (default false) where true means that the annotated mode is the default for all children in the serialization tree (not type tree).