Use ReentrantLocks instead of synchronized blocks

[pjfanning]

I don't think the existing synchronized code stops multiple creations of mappers.

The new lock code double checks that the mappers are not initialized. The new locking is optimistic - we don't lock and only lock when we know we need to lazily create instances.

[cowtowncoder]

I don't see much value in doing any of this proactively.

Let's wait until someone actually requests these changes.

EDIT: changed my mind, see later comments.

[pjfanning]

I don't see why locking this code helps.

    public synchronized ObjectMapper getConfiguredMapper() {
        /* important: should NOT call mapper(); needs to return null
         * if no instance has been passed or constructed
         */
        return _mapper;
    }

How are we sure that whatever is locking is creating the _mapper? It could be just another getConfiguredMapper call.

[cowtowncoder]

I don't see why locking this code helps.

    public synchronized ObjectMapper getConfiguredMapper() {
        /* important: should NOT call mapper(); needs to return null
         * if no instance has been passed or constructed
         */
        return _mapper;
    }

How are we sure that whatever is locking is creating the _mapper? It could be just another getConfiguredMapper call.

Yeah that seems dubious, not sure why it is synchronized.

----But my bigger point is that none of these methods seems likely at all to become synchronization hotspot.---
----So there seems to be no point in making changes; fixing what isn't necessarily broken (even if starting from scratch would be written differently).----

[cowtowncoder]

Hmmh. Actually, I take that back -- this could have measurable performance impact. Given that getMapper() call is made for each request served.

So yeah, maybe it's worth doing after all.

[cowtowncoder]

@pjfanning Merged and I think this makes sense. Would it be possible to get similar PR for https://github.com/FasterXML/jackson-jakarta-rs-providers ?