Why always full class name when using default typing ?

[Mumeii]

Hi Jackson's user community.

TL;DR :

I've seen in the ObjectMapper class's code that whenever using the activateDefaultTypingAsProperty, there is no choice using something else than the full class name typing :

    public ObjectMapper activateDefaultTypingAsProperty(PolymorphicTypeValidator ptv,
            DefaultTyping applicability, String propertyName)
    {
        TypeResolverBuilder<?> typer = _constructDefaultTypeResolverBuilder(applicability,
                ptv);
        // we'll always use full class name, when using defaulting
        JsonTypeInfo.Value typeInfo = JsonTypeInfo.Value.construct(JsonTypeInfo.Id.CLASS, JsonTypeInfo.As.PROPERTY,
                propertyName, null, false, null);
        typer = typer.withSettings(typeInfo);
        return setDefaultTyping(typer);
    }

How comes ?

For terseness I'd like to use a shorter strategy.

Is it possible while still using default typing without encountering ugly troubles ?

Further explanation of my context :

Disclaimers :
I know default typing is not recommended and that the selective usage of @JsonTypeInfo is.

But I'm encountering troubles using it 😋 :

My context is a Spring Boot application using many @cachable annotations, and storing them in a redis cache

I want to replace the default java serialization system for Jackson one.

To do so, I'm using the GenericJackson2JsonRedisSerializer class.

I know I can use a non Generic version but it would necessistat to define as many cache managers than we have of kind of cached types, which would be cumbersome because we have many many (many).

Unfortunately, GenericJackson2JsonRedisSerializer don't seems to work fine whenever the cached objects are more complexe as one of my DTO objects; such as :

• Locale
• List< MyDto >
• Map< Integer, MyDto >
• ...

I was expecting it would work out of the box, but unfortunately, no matter I build it the following way :

	@Bean( "jsonValueSerializer" )
	public GenericJackson2JsonRedisSerializer jacksonJsonValueSerializer( final ObjectMapper springObjectMapper ) {
		return GenericJackson2JsonRedisSerializer
			.builder()
			.typeHintPropertyName( "@" )
			.defaultTyping( true )
			.objectMapper( springObjectMapper )
			.build();
	}

things doesn't work well in the previously mentioned cases.

I guess it's mostly because of the type erasure that occur on generic collections returned by methods annotated with @Cacheable.

That's why I've defined my own version of GenericJackson2JsonRedisSerializer, and setup an extra AOP layer along with it.

It enable to enforce the deserialization type startup point : the AOP layer fetch it from the (type erased) Method return type where @cachable annotation is placed.

And with a few extra home made annotations, it's possible to enforce the right JavaType for cases such as Map< Integer, MyDto >,, to avoid having Strings keys used instead of Integer ones upon cache retrieval for example.

The whole thing is working fine so far, but I still need to have type informations placed in the produced JSON strings, and I can't picture another way to do so than to user a mapper where I've activateDefaultTypingAsProperty

Whenever I try simply use @JsonTypeInfo instead of activateDefaultTypingAsProperty (without @JsonSubTypes, as my DTOs don't really have ones) the type informations are not serialized, which seems to be the intended behavior

So, in the end, I'm wondering if there is an in between way to configure the whole thing without being forced to use activateDefaultTypingAsProperty and the full class name typing coming along

Looking for your advices about it 😋

[cowtowncoder]

Ok, so, "Default Typing" really has to (I think) be based on class names, not type names, as it can cover all kinds of classes. It does not seem plausible to -- in general -- use type names, for deserialization. Or conversely, when using type names, @JsonTypeInfo is probably already used on a closed (not open-ended) set of classes.

Beyond this, the other class name option -- "MINIMAL_CLASS" -- is based on relative Java package name compared to that of base type. That wouldn't work in general as ultimately the only true base type in "Default Typing" case is java.lang.Object... and that does not seem like useful as basis to calculate relative class names of (given that one cannot really add types under java.lang, or java. in general.

As to alternatives to Default Typing, I always advocate for a simple wrapper type like:

public class Wrapper {
  @JsonTypeInfo(...)
  public Object w;
}

in which case you should get mostly default typing behavior, forcing polymorphic handling of NON-generic root value. I am not sure why this is not more widely used as "the polymorphic handling wrapper" pattern but here we are.