new LookupCache interface (3.0 release)

[pjfanning]

Aim is to allow the the type cache implementation to be pluggable.

SimpleLookupCache is the default implementation. Users can write their own implementaions based on other caching frameworks, like Caffeine, if they prefer. Jackson-databind having an interface means that we can have pluggability and not introduce new jar dependencies.

[cowtowncoder]

Sounds good -- I add this on my WIP list of things. May take a while only as I am furiously trying to close 2.10 functionality, otherwise I think should be quick to go through.

[pjfanning]

@cowtowncoder I have a caffeine based cache that will work with jackson 2.9./2.10 - https://github.com/pjfanning/jackson-caffeine-cache/blob/master/src/main/java/com/github/pjfanning/jackson/CaffeineLookupCache.java

[ben-manes]

@pjfanning Why not return the results from the asMap write methods instead of performing a get first?

[pjfanning]

@ben-manes good point - I had left those lines behind from an earlier iteration

[cowtowncoder]

@pjfanning Neat (wrt Caffeine-based impl). Would be nice to document somehow -- one of many things discussed at some point was that of how to support "Jackson Util" or "Jackson Ext", some form of place to contain helpful implementations, outside of core components but in usable form. For some things could be source go copy, for others small jar.

[cowtowncoder]

So, I merged the PR, but got to thinking on part of how to make things configurable.
Immediately there are couple of questions:

1. For many cases, it might be sufficient to just change max size -- but not same for all uses
2. It may be necessary to provide a "supplier" (factory) of caches, not cache instance
3. There are a few places and potential explosion in state, even if using ObjectMapper.Builder()

So then I realized that maybe, instead of making individual cache things configurable separate, there ought to be something like CacheProvider (or -Supplier or even Caches to follow naming semi-convention)? It would have separate named method for all distinct cache types we need (possibly with suggested max size? not sure about this); and there would be a default implementation just provides SimpleLookupCache instances. Idea would be to sub-class it, override what is needed.
Default implementation could have some amount of configurability wrt sizes.
Or perhaps we'd have both default implementation and simple "Base" that makes all other methods by default call a single abstract method: this to be used as base-class for custom implementations.
Either way, doing this would allow addition of new cache types in provider over time, without having to add new things in ObjectMapper.Builder.

One secondary benefit would be to sort of document all caches Jackson databind uses.
Custom providers could not only add more optimal cache implementations, but also support metrics generation, for most advanced use case.

[pjfanning]

I guess it's best to come back to this after the 2.10.0 release is complete. I do favour the idea of being able to set a CacheProvider implementation in the MapperBuilder and us providing a default that uses SimpleLookupCache.

[cowtowncoder]

Yes, agreed. I just wanted to write down broad idea I had, so I won't forget :)

[cowtowncoder]

Created #2502 for the follow-up part.