[Feedback wanted] pluggable implementatation of Type Cache

[PJ Fanning]

There is an open issue relating to potential performance problems with caching too many types. In Jackson 2.9 and 2.10, the implementation is LRUMap. The class is renamed is for the 3.0 release (SimpleLookupCache).

The key methods are get, put, putIfAbsent, size and clear. I would suggest that if we had a LookupCache interface, we could allow users to write their own cache implementations (probably wrapping a 3rd part cache implementation like Caffeine). This would avoid Jackson having dependencies on other jars but allow individual users to inject a type cache that best suits their needs.

In TypeFactory, we could add a new method alongside the existing withCache(LRUMap<Object,JavaType> cache) - maybe withCache(LookupCache<Object,JavaType> cache).

[Tatu Saloranta]

This sounds like a good idea, in general. With 3.0 we can just go
ahead and change APIs (add new type, make existing class implement
it). But with 2.x we'd have to add overloads.

Due to timing it looks bit tight on 2.10, although if you would like
to have a go I'd be happy to review PR?

For what it is worth I think pluggability was discussed at some point,
regarding one of caches (but I don't remember which one).
One challenge wrt pluggability earlier was possible need to provide
cache factories, not caches.
This is where Java 8 would help, could use `Supplier<T>`

However... with 2.10 adding Builder approach, it may not be necessary
to have Supplier/Factory either: and more importantly we can extend
ObjectMapper.Builder API safely and without bloating main ObjectMapper
use API.

-+ Tatu +-