Add new DefaultTyping.NON_FINAL_AND_ENUMS to allow Default Typing for Enums

[JooHyukKim]

As title says, allow default type handler for Enum's.
Fixes #3569

[JooHyukKim]

This PR is against '2.15' branch at the moment, but with possible rebasing to '2.16' branch in mind.

I am leaning toward merging into '2.16', since version '2.15' is sort of mature already 🤔.. WDYT @cowtowncoder ?

[cowtowncoder]

This PR is against '2.15' branch at the moment, but with possible rebasing to '2.16' branch in mind.

I am leaning toward merging into '2.16', since version '2.15' is sort of mature already 🤔.. WDYT @cowtowncoder ?

If this was to be applied, definitely 2.16: seems quite risky change to existing behavior.
(also not sure this makes sense in general but that aside)

[JooHyukKim]

If this was to be applied, definitely 2.16: seems quite risky change to existing behavior.

Rebased to 2.16, thanks! 🙏🏼

[JooHyukKim]

My apologies, after re-reading #4159 (comment), I realized that if I called activateDefaultTyping() configuration with DefaultTyping.EVERYTHING, the test passes, as per #3569 (comment).

[cowtowncoder]

@JooHyukKim Btw, if for some reason we do want to enable inclusion of polymorphic type for Enums, we could and should simply add a new DefaultTyping value -- not modify NON_FINAL but add something like NON_FINAL_AND_ENUMS.
I'd have no problem with that.

[JooHyukKim]

@JooHyukKim Btw, if for some reason we do want to enable inclusion of polymorphic type for Enums, we could and should simply add a new DefaultTyping value -- not modify NON_FINAL but add something like NON_FINAL_AND_ENUMS. I'd have no problem with that.

Oh, I thought adding another DefaultTyping would be too much :))) NON_FINAL_AND_ENUMS sounds perfect 👍🏼 Will work on it later today and let's see how it looks. Thank you again! @cowtowncoder

[cowtowncoder]

@JooHyukKim Btw, if for some reason we do want to enable inclusion of polymorphic type for Enums, we could and should simply add a new DefaultTyping value -- not modify NON_FINAL but add something like NON_FINAL_AND_ENUMS. I'd have no problem with that.

Oh, I thought adding another DefaultTyping would be too much :))) NON_FINAL_AND_ENUMS sounds perfect 👍🏼 Will work on it later today and let's see how it looks. Thank you again! @cowtowncoder

Yeah, realistically changing behavior of an existing choice is bigger change than adding a new one (unless I am missing something). We don't want dozens of DefaultTyping options, and users can quite easily create their own alternatives.
But if there is need to replace some use cases of DefaultTyping.EVERYTHING it's worth it.

[cowtowncoder]

LGTM. Will try to get merged ASAP.

[cowtowncoder]

Also realized that the only reason to need NON_FINAL_AND_ENUMS is this complicated combination of generic types as root values, with polymorphic typing.

In general, use of generic (parameterized) types as root values as an Anti-Pattern for Jackson and should be avoided; particularly so if polymorphic type handling is needed.
Proper way to handle this is to remove generic type from root value, either by:

1. Sub-classing generic type to make it concrete, OR
2. Using a non-generic wrapper -- parametric types are perfectly fine anywhere below root value.

So instead of trying read and write MyWildBaseType<T> itself, wrap it in something like:

public class MyWrapper {
   @JsonTypeInfo // no longer any need for DefaultTyping!
   public MyWildBaseType<T> value;
}

// or even
public class MyPlainWrapper {
   @JsonTypeInfo // no longer any need for DefaultTyping!
   public Object value;
}

and things work without special handling -- including NO DEFAULT TYPING needed! -- when we avoid generics and polymorphism for root value, and get reliable base type from Field/Method declaration