Add option to resolve type from multiple existing properties (@JsonTypeInfo(use=DEDUCTION))

[bytesandwich]

Rather than forcing the creation of an additional typeId property, or class info, determine the type by its natural properties. Possible As.EXISTING_PROPERTIES, and register a TypeResolver that returns the JavaType by inspecting the object.

Given a type hierarchy, naturally subtypes have additional fields and their type can likely be determined simply by inspecting the fields.

[cowtowncoder]

This would be nice, if such information was available, but Jackson does not construct an intermediate Object model during parsing and data binding. Further, existence of sub-fields (of subtypes) can only be handled once type of the value is determined, so this can lead to chicken-and-egg problem.

Now, while difficult, this is not impossible: buffering would however need to change from using TokenBuffer into JsonNode (meaning additional overhead to allow access). Introspection there would be done using basic tree traversal, as Java types are not available, although property definitions may be known.

TypeResolver, however, has no way of accessing such information. It is not designed to take in more complex information than a String. So that part would not work for implementation.

I am open to contributions, as usual.

[bytesandwich]

Maybe just the name of the properties should be available?

[cowtowncoder]

Those could conceivably be buffered more easily, yes.

On serialization side I suppose things would be easier, since this option would essentially be of type "no type information is added" (but can still go through the same path as "AS_PROPERTY" variant).
On deserialization it would need to be assumed that input is of type JSON Object, which would simplify handling.

Since TypeDeserializer has full power over JsonParser, it could read through properties, and buffer things -- depending on exactly how logics would be used, it might even be able to short-circuit some processing (buffer some, but not necessarily all content).

It is possible that such an approach really should just build a JsonNode or TokenBuffer (from which JsonNode - tree could be built efficiently if need be), and even by-pass TypeIdResolver, because TypeIdResolver interface can not be modified for 2.x (interfaces are very fragile, and in general one can not add new methods without breaking backwards compatibility).
But we could also define an extended TypeIdResolver, if extensibility is important. Which it probably is, since that is the customizable part.

With extended version, resolver could actually indicate amount of information it requires. Although I think TokenBuffer might be as good as it gets, since it is efficient representation (of all tokens), from which name set can be derived, JsonNode tree built and so on.

So I guess this is actually doable. :-)

For what it is worth, something like this has been requested earlier:

http://jira.codehaus.org/browse/JACKSON-500

so I am not questioning value of such a feature.

[cowtowncoder]

See #1100 for pssible additional ideas.

[cowtowncoder]

Being worked via PR #2813.

[cowtowncoder]

Implementation complete, thanks to @drekbour 's impressive contribution! Looking forward to inclusion in 2.12.0.