Immutable JsonMapper

[jaewoongchoi1]

What about supporting an immutability option for the JsonMapper as a builder property? An immutable JsonMapper would throw an exception (e.g., java.lang.UnsupportedOperationException) if any mutating method is called (e.g., {configure, enable, disable}(XXXFeature ...)).

This feature would be helpful in use cases where one wants to share a pre-configured mapper instance in many places and prevent any accidental mutation efforts (custom further configurations).

[jaewoongchoi1]

My current "best-effort" approach is to create a subclass of JsonMapper (as a copy-constructor) and override all mutating methods to throw the exception. The caveat is that any new mutating method may come in a later version that this class would miss.

public class ImmutableJsonMapper extends JsonMapper {

    ImmutableJsonMapper(@Nonnull final JsonMapper original) {
        super(original);
    }

    @Override
    public ObjectMapper addHandler(DeserializationProblemHandler h) {
        throw new UnsupportedOperationException(errorMessage);
    }

    @Override
    public ObjectMapper addMixIn(Class<?> target, Class<?> mixinSource) {
        throw new UnsupportedOperationException(errorMessage);
    }

    @Override
    public ObjectMapper clearProblemHandlers() {
        throw new UnsupportedOperationException(errorMessage);
    }

    @Override
    public ObjectMapper configure(DatatypeFeature f, boolean state) {
        throw new UnsupportedOperationException(errorMessage);
    }

    @Override
    public ObjectMapper configure(DeserializationFeature f, boolean state) {
        throw new UnsupportedOperationException(errorMessage);
    }

    @Override
    public ObjectMapper configure(JsonParser.Feature f, boolean state) {
        throw new UnsupportedOperationException(errorMessage);
    }

   // ... same overriding for all other mutating methods; {enable,disable,set,...}(XXXFeature ...)
}

[cowtowncoder]

For now, I think that is the way you should approach this: as per my comment, I am -1 on trying to make something like this to be part of Jackson 2.x. I have thought about it in the past, in context of (also) removing checked exceptions; and there are multiple problems -- including but not limited to there being dozen of subtypes of ObjectMapper (for each format). So it wouldn't work for non-JSON mappers.

[pjfanning]

I think the plan is that Jackson 3 would remove some of these methods and that users would more or less be required to use the builder.
I am not a big fan of having methods and then having them throw 'unsupported' exceptions. If this was to make sense in Jackson 2, I would suggest that you create a new ImmutableJsonMapper class that wraps a JsonMapper but that the ImmutableJsonMapper only has the methods that it supports.

[jaewoongchoi1]

A new whitelisting interface/class approach makes sense if there is no existing usage of such instances. I suggested a subclass approach because of the existing typing/casting usage of such an instance in the current (considerable size of) codebase spanning multiple repositories/packages. For example,

ObjectMapper mapper1 = MyMapperFactory.getDefaultMapper();
// or
final var mapper2 = MyMapperFactory.getDefaultMapper();
doSomethingWithJsonMapper(mapper2);

void doSomethingWithJsonMapper(JsonMapper mapper) {
   ...
}

An introduction of a new type (and switching to it) would be too destructive in this case.

[cowtowncoder]

I agree with @pjfanning

Jackson 3.0 (in master) has immutable JsonMapper -- not just parts but it is completely immutable, by-design -- and I do not want to spent lots of effort in trying to make 2.x kind-of immutable.
I did initially (few years back) try to think of wrapper approach, but fundamentally I do not think it is worth the effort to try to catch mutations; and it would be more confusing to users.

So I am -1 on trying to do something like this for Jackson 2.x.

[Liveitabhi14]

I am using ObjectMapper in my spring boot project, and have created a bean for it.
When I analyzed the perf test result of one of the APIs, I noticed that there is a lock contention scenario arising due to the usage of objectMapper's convertValue() method.
The use case is very straightforward - configure objectMapper once at the start of the application and then use it later on for pojo conversions. But still, the synchronized block, probably added to make the mapper thread-safe, is becoming a bottleneck here.

Doesn't this scenario make it worth the effort? In my opinion, its a very common case as creating new ObjectMapper instances every time is not recommended due to its "heaviness".
Or is there another way or solution already available that I am missing here?

[cowtowncoder]

@Liveitabhi14 The sync block is very unlikely to have anything to do with immutability or lack thereof; let's not assume dependency where there is none.

Put another way, synchronization issues would need to be tackled separately; they are usually due to construction and caching of (de)serializers; mutable state that does exist independent of configuration.

So no, that kind of issue is orthogonal wrt immutability of ObjectMappers.

[JooHyukKim]

Agreed with @cowtowncoder. Let's separate concerns here.
Synchronization issues mostly happen during warm-up process (Warm-up meaning initial constructing-then-caching of deserializers).