support disallow list for default typing

[pjfanning]

Is your feature request related to a problem? Please describe.

The idea is that when mapper activateDefaultTyping is enabled that not every class name would be written into the serialized JSON. For me, this default typing feature is useful when you have a class like record MyRecord(int id, MyInterface interface) where MyInterface is a basic interface (or sealed class) and there are a few possible subclasses of MyInterface.

In https://github.com/FasterXML/jackson-module-scala/issues/643, we don't really want a Map implementation class name to be written. jackson-module-scala doesn't need help with filling in a Scala Map. In fact, the class name in the serialized JSON persuades jackson-databind to try to build the Map instead of letting jackson-module-scala build it.

What I am suggesting is that when activateDefaultTyping is used, that all classes are affected (as happens now) but that we add a new method that lets users block this from happening for certain classes. It would be nice if this supported package names as well as class names. So the input would be a String or List of Strings but the individual String could be the package name and we could do a startsWith check.

Describe the solution you'd like

Serialized JSON would not include class names where they matched a disallowed class/package name. Ideally deserialization would also ignore any classes that matched a disallowed class/package name.

something like: void defaultTypingIgnores(String... names)

Usage example

No response

Additional context

No response

[JooHyukKim]

Perhaps we could consider adopting a fluent style, such as:

   .activateDefaultTyping(...)
   .except(Package.withNameMatching("com.jackson.some"))

This approach might offer more flexibility, especially if we anticipate more matching mechanisms in the future.

However, the tradeoff from a development perspective is that it's more verbose and would require much more additional effort.

[cowtowncoder]

We already have DefaultTyping enumerations for determining when Type Id is to be included. So maybe something could be added to allow similar extension point for users. I am not too excited about supporting List of class names of type to exclude since that won't scale very well.

[marilatte53]

I am currently facing a similar issue, since I want to deserialize JSON into a POJO containing nested classes with interface properties. My idea is to let users create a POJOs via a JSON file, however I only want specific interfaces (that are dynamically added to a list) to be resolved via type ids. For example instead of List I want to always use ArrayList and ignore any possible type ids. I think this would be possible, if the AsArrayTypeDeserializer supported default implementations, but the responsible code is commented out:

// 11-Nov-2020, tatu: I don't think this branch ever gets executed by
//    unit tests so do not think it would actually work; commented out
//    in 2.12.0
/* if (_defaultImpl != null) {
        p.nextToken();
        return _idResolver.idFromBaseType();
    }
*/

Maybe what I'm doing is completely wrong and there is a better solution. Alternatively, I could probably use a custom Deserializer.