20
20
* This is an extension of {@link TypeIdResolver} for serializing and deserializing polymorphic types. The vanilla
21
21
* implementation of TypeIdResolver only enables a single type id to be serialized with a value, which is not always
22
22
* sufficient for every consumer of a value with polymorphic typing to identify and instantiate the appropriate type.
23
- * <p/ >
23
+ * <p>
24
24
* This allows more robust polymorphism support, in that consumers of a serialized polymorphic object do not need
25
25
* complete type information. As long as their deserializer can resolve (or, understand) one of the annotated type ids,
26
26
* they can still perform polymorphic deserialization. An example:
27
- * <p/ >
27
+ * <p>
28
28
* <pre>
29
29
* class BasicMessage {
30
30
* String id;
33
33
* class SocialMediaMessage extends BasicMessage {
34
34
* boolean cool;
35
35
* }
36
- *
36
+ *</pre>
37
37
* Let's say we serialized a value into:
38
- *
38
+ *<pre>
39
39
* {id="123",message="hi",cool=false}.
40
- *
40
+ *</pre>
41
41
* The existing polymorphism support may have annotated this as the following Ion:
42
- *
42
+ *<pre>
43
43
* SocialMediaMessage::{id="123",message="hi",cool=false}
44
- *
44
+ *</pre>
45
45
* But a consumer who only has BasicMessage in its classloader won't know (or care) what a SocialMediaMessage is, and be
46
46
* stuck. Using this interface enables the following serialization:
47
- *
47
+ *<pre>
48
48
* SocialMediaMessage::BasicMessage::{id="123",message="hi",cool=false}
49
- *
49
+ *</pre>
50
50
* About particular implementations:
51
- * <p/ >
51
+ * <p>
52
52
* Ion serialization should be using {@link IonAnnotationTypeSerializer}, which is polymorphism-aware, but how should a
53
53
* MultipleTypeIdResolver handle a call to the non-polymorphic {@link TypeIdResolver#idFromValue(Object)}? I'd probably
54
54
* do something like {@code return selectId(idsFromValue(value)); }, to keep things working when serializing
@@ -72,7 +72,7 @@ public interface MultipleTypeIdResolver extends TypeIdResolver {
72
72
* {@link TypeIdResolver#typeFromId} to get a {@link com.fasterxml.jackson.databind.JavaType}. It is a invariant
73
73
* on this method that its output, if non-null, be valid input for {@link TypeIdResolver#typeFromId} of the
74
74
* same TypeIdResolver instance.
75
- * <p/ >
75
+ * <p>
76
76
* Note that we're not resolving the array of ids directly into a JavaType because there is code (in the Jackson
77
77
* package, not ours) which consumes the id String itself, not the JavaType object.
78
78
*
0 commit comments