There is an open issue <https://github.com/FasterXML/jackson-module-scala/issues/428> relating to potential performance problems with caching too many types. In Jackson 2.9 and 2.10, the implementation is LRUMap <https://github.com/FasterXML/jackson-databind/blob/2.10/src/main/java/com/fasterxml/jackson/databind/util/LRUMap.java>. The class is renamed is for the 3.0 release (SimpleLookupCache <https://github.com/FasterXML/jackson-databind/blob/master/src/main/java/com/fasterxml/jackson/databind/util/SimpleLookupCache.java> ).
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 <https://github.com/ben-manes/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 <https://github.com/FasterXML/jackson-databind/blob/2.10/src/main/java/com/fasterxml/jackson/databind/type/TypeFactory.java>, we could add a new method alongside the existing withCache(LRUMap<Object, JavaType> cache) - maybe withCache(LookupCache<Object,JavaType> cache). -- 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 jackson-dev+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/jackson-dev/4da57fb8-fb76-483f-97f6-5eb563373e35%40googlegroups.com.
