How to serialize generic/polymorphic objects starting with 2.12.0-rc2?

[piakbt]

Hello community!

Recently I raised jackson-databind version in my project because of vulnerabilities and ran into something unexpected.
Please help me understand what's changed in jackson-databind 2.12.0-rc2 and how to deal with it.

I have this code (it's synthetic just for illustration, but it has the same structure as in the project code):

import com.fasterxml.jackson.annotation.JsonSubTypes;
import com.fasterxml.jackson.annotation.JsonTypeInfo;
import com.fasterxml.jackson.annotation.JsonValue;
import com.fasterxml.jackson.core.JsonProcessingException;
import com.fasterxml.jackson.databind.ObjectMapper;
import lombok.AllArgsConstructor;

import java.io.Serializable;

public class Main {
    public static void main(String[] args) throws JsonProcessingException {
        ObjectMapper mapper = new ObjectMapper();
        JustT<Method> t = new JustT<>(new MedianMethod());
        System.out.println(mapper.writeValueAsString(t));
    }
}

@JsonTypeInfo(use = JsonTypeInfo.Id.NAME, include = JsonTypeInfo.As.PROPERTY, property = "type")
@JsonSubTypes({
        @JsonSubTypes.Type(value = MeanMethod.class, name = "Mean"),
        @JsonSubTypes.Type(value = MedianMethod.class, name = "Median") })
interface Method extends Serializable {
}

class MeanMethod implements Method {
}
class MedianMethod implements Method {
}

@AllArgsConstructor
class JustT<T> {
    private T o;
    @JsonValue
    public Object getValue() {
        return o;
    }
}

With jackson-databind 2.12.0-rc1 and below the output is:

{"type":"Median"}

But with jackson-databind 2.12.0-rc2 and above it is:

{}

Why is that? How to keep the type in a serialized value?

[JooHyukKim]

@piakbt Idk what changed between the two 2.12.0-rc versions though.

Can you try below Java code? Below works in latest jackson-databind 2.12 branch. To point out the difference...

• Using .writerFor(new TypeReference<JustT<Base>>(){}), and
• And @JsonValue annotated method returns T. Check out @JsonValue documentation

    public void testSer() throws Exception {
        // provide typeReference
        ObjectWriter writer = new ObjectMapper()
                .writerFor(new TypeReference<JustT<Base>>(){});
        
        String output = writer.writeValueAsString(new JustT<Base>(new MedianMethod()));
        
        assertEquals("{\"type\":\"Median\"}", output);
    }

    @JsonTypeInfo(use = JsonTypeInfo.Id.NAME, include = JsonTypeInfo.As.PROPERTY, property = "type")
    @JsonSubTypes({
            @JsonSubTypes.Type(value = MeanMethod.class, name = "Mean"),
            @JsonSubTypes.Type(value = MedianMethod.class, name = "Median") })
    interface Base extends Serializable {
    }

    class MeanMethod implements Base {
    }
    class MedianMethod implements Base {
    }

    class JustT<T> {
        
        private T o;
        
        // Instead of Object, use T here
        @JsonValue
        public T getValue() {
            return o;
        }

        public JustT(T o) {
            this.o = o;
        }
    }

Wrt vulnerabilities, I would recommend upgrade to latest stable version 2.15 because most probably 2.12 version won't receive security patches

[JooHyukKim]

you can use existing instance, like

       // get existingMapper from somewhere....
        ObjectWriter writer = existingMapper.writerFor(new TypeReference<JustT<Base>>(){});

[JooHyukKim]

You may check out documentation writerFor.

[piakbt]

Understand.

I need to be more precise: the 3rd library I use is dnanexus-api, DXUtil.getJobInput() javadoc
It creates the mapper and maps value on its own.

But anyway, is it okay that the behavior of jackson-databind changed between the versions? I've looked at pull-requests for 2.12.0-rc2 milestone and didn't find the one that brought changes here. Also I haven't found this in changelog...

What I found is that the code of JsonValueSerializer class noticeably changed between rc1 and rc2.

While in rc1 the serializer for the provided example was created as
ser = prov.findTypedValueSerializer(c, true, this._property);
and ultimately as
ser = new TypeWrappedSerializer(typeSer, (JsonSerializer)ser);
then in rc2 it became
ser = this._findDynamicSerializer(ctxt, value.getClass());
and ultimately
ser = this._createAndCacheUntypedSerializer(valueType);

[piakbt]

@JooHyukKim although the code example that I posted required to both change Object to T and create an instance of a Writer, my project code worked different. It was enough just to change Object to T. So I marked your reply as an answer. Thank you very much!

[JooHyukKim]

But anyway, is it okay that the behavior of jackson-databind changed between the versions? I've looked at pull-requests for 2.12.0-rc2 milestone and didn't find the one that brought changes here. Also I haven't found this in changelog...

I am not sure whether the change was intended or not, but I don't think Jackson 2.12 will cover any additional fixes, as per documentation of jackson-databind module doc.

@JooHyukKim although the code example that I posted required to both change Object to T and create an instance of a Writer, my project code worked different. It was enough just to change Object to T.

Okay, glad it helped!

[cowtowncoder]

One minor note: use of 2.12.0-rc2 is fundamentally wrong: all rcs are pre-release versions that should NEVER BE USED after actual matching release (first 2.12.0) is out. And generally before reporting a problem it is necessary to try out the latest patch version of that minor version as well (2.12.7).

And as an additional sidenote: while there are questions of versions compatibility, it is usually not a good way to ask about behavioral change as much as whether the later version has expected behavior -- behavior is, after all, typically changed when a bug is fixed. It might be regression (breakage), but ultimately the question is whether observed new behavior is (more) correct or not.

Put another way: only report bugs for changes where the new behavior appears incorrect, and focus on showing the problem. Not asking about change in behavior.

I mention above things because they seem to be recurring challenges with bug requests and discussions: not because this one was particularly problematic.