Deprecate `ObjectMapper.canDeserialize()`/`ObjectMapper.canSerialize()` in 2.18

[cowtowncoder]

(note: offshoot of discussion in #4568)

As per #1917 there is limited value in these 2 methods (and underlying machinery), and hence they are dropped from 3.0, as we cannot drop them from 2.x due to backwards-compatibility requirements.
But since the fundamental problem exists, we should mark them as @deprecated in 2.x (specifically, 2.18).

[JooHyukKim]

Along with deprecating the two methods, shall we come up with alternative way to achieve the same functionality which may be added to deprecated methos' javadocs so users know what to do later on?

[cowtowncoder]

@JooHyukKim There isn't really matching functionality, unfortunately: there is no good way (that I know of) to figure it in useful manner whether something is reliably (de)serializable; from what kind of input and so on. Calling applications should not -- for example -- try to obtain serializer or deserializer.

I am +1 on improvements to Javadocs, just not sure what to say other than "these seemed like a good idea but weren't".

[ciscoo]

@cowtowncoder I think the Javadoc or the deprecation should mention what you said in the comment. As it stands, the "use discouraged" is unhelpful IMO. And if possible, provide an alternative solution.

My use case for it is for testing that my module setup correctly:

class ExampleApiJacksonModuleTests {

    private ObjectMapper objectMapper;

    @BeforeEach
    void setUp() {
        this.objectMapper = new ObjectMapper();
        this.objectMapper.registerModule(new ExampleApiJacksonModule());
    }

    @Test
    void registersDeserializers() {
        assertThat(objectMapper.canDeserialize(
                        objectMapper.constructType(new TypeReference<ExampleRequest>() {})))
                .isTrue();
        assertThat(objectMapper.canDeserialize(
                        objectMapper.constructType(new TypeReference<ExampleResponse>() {})))
                .isTrue();
        assertThat(objectMapper.canDeserialize(objectMapper.constructType(new TypeReference<IntentRegistry>() {})))
                .isTrue();
    }

    @Test
    void registersSerializers() {
        assertThat(objectMapper.canSerialize(ExampleRequest.class)).isTrue();
        assertThat(objectMapper.canSerialize(ExampleResponse.class)).isTrue();
    }
}

Note I have other tests that test against JSON and that may be the only solution to the above -- test serialization/deserialization against live/real JSON.

[JooHyukKim]

@ciscoo I concur. I filed #4826 hoping for a bit of improvement on existing usage cases.

[cowtowncoder]

@ciscoo in your case, you really should just verify serialization/deserialization works correctly. canSerialize() and canDeserialize() are removed because they really cannot determine properly whether there is real ability to serialize/deserialize, given that (de)serializers are dynamically added via callbacks; could have fall-back "Bean" (de)serializer and so forth.
So they can essentially return both fall positives and negatives.

I hope @JooHyukKim 's javadoc improvements help.

[ciscoo]

@cowtowncoder Yes, I have tests for that today using raw/real JSON which works fine. The added javadoc from @JooHyukKim is indeed helpful.

For those that want more of the why or nitty-gritty details can look at the git blame and refer back to this issue which is how I landed here originally.

[cowtowncoder]

It is too bad because intuitively these methods have simple straight-forward names and seemingly simple semantics. It is unfortunate they really cannot be well implemented, with pluggable (de)serializers, various failure modes etc.

This just as background for deprecation.