On Fri, Sep 13, 2019 at 1:28 PM PJ Fanning <[email protected]> wrote: > > 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).
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 +- -- You received this message because you are subscribed to the Google Groups "jackson-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/jackson-dev/CAL4a10isyNa52OX7VLTJ-dT3KS3OqaDC%2B18CTVWmAWtzi%2BmAEg%40mail.gmail.com.
