On Tue, Mar 28, 2023 at 4:30 PM Viktor Szathmáry <[email protected]> wrote: > > > On Mar 29, 2023, at 00:58, Tatu Saloranta <[email protected]> wrote: > > Yes, I think that shows a simple idea that could work as intended (in > this case, for `String` -valued properties. > > > > Seems to work after creating a child with the canonicalize flag set (the root > throws and without the flag no actual interning seems to happen). > > private final static CharsToNameCanonicalizer can = > CharsToNameCanonicalizer > .createRoot() > .makeChild(JsonFactory.Feature.CANONICALIZE_FIELD_NAMES.getMask()); > > Since there are multiple fields with the custom deserializer applied (thus > multiple deserializer instances) but I want them to share a string pool, I > have also made it static. Is this thread-safe? I’m not sure I fully > understand the parent/child relationship in CharsToNameCanonicalizer... > > Also, what’s the expected behavior in case the string pool gets large? >
Good questions. I may have spoken too soon -- I forgot that the thread-safety is due JsonParser instances having "child" instances, and only syncing when "returning" internal state to parent instance. This is very different from stateless deserializers where there does not exist a similar life-cycle (for parsers, the life-cycle is for reading a single document). So I am not sure this approach actually works (or even can work). Behavior is to clear the whole cache if it reaches critical size; it's not designed as a LRU cache but more for a bounded set of names (so clearing up is a defensive mechanism for an unexpected situation). -+ Tatu +- -- You received this message because you are subscribed to the Google Groups "jackson-user" 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-user/CAL4a10itfx10aac2Em4VTuk2X2vRZY1eG_vxYC9XJ7gY96d%2BhA%40mail.gmail.com.
