1. JsonNode doesn't actually have any magic under the hood. It uses Map<String, JsonNode> for objects, List<JsonNode> for arrays and wrapper objects for primitive types. Therefore, it's not memory efficient IMO so it actually depends on your priorities: 1.1. If you care about the code complexity compared to memory bottleneck or doesn't really have any schema, I would stick with JsonNode as it's feature-rich and well-documented. 1.2. If you care about the performance and doesn't really have any option to use class data binding, you may write your custom parser and deserialize the JSON blob into a more compact representation such as Apache Avro rather than JsonNode. If you have a metadata store, you can basically parse the JSON blob, validate it and convert them into Avro instances which will occupy less heap memory. We prefer this approach as it also provides us a native way to validate the JSON blob.
2. AFAIK, JsonNodeFactory is thread-safe and stateless but it would be better if someone who has experience with it could answer this question. On Tuesday, February 26, 2019 at 11:48:13 PM UTC+3, [email protected] wrote: > > Hello, > > In a code base I have been working on for more than a year, we receive > JSON (as byte[] from queue), we transform JSON, and we persist JSON (to > Elasticsearch). In the initial design, tempted by its convenience, we made > the mistake of representing the JSON as java.lang.Object in this JSON > pipeline. Transformation functions receive Object and spit out Object. > Though this introduced other problems (e.g., certain types like Set<V> do > not map 1-to-1 to JSON, variable types do not properly communicate the > intent of the value, lost caching and object pooling opportunities, etc.) > revealed themselves in pretty late stages of the development. If I would > have been starting from scratch today, I would pick Jackson's JsonNode as > the only allowed JSON type. Though getting off the beaten path might raise > other issues that we cannot oversee right now and this is where my question > comes into play. > > 1. What are the best practices to represent JSON documents to allow > efficient read/write/update operations? (Note that in our case there is no > schema, hence no class data binding.) > 2. If one would use JsonNode, what are the best practices for using > JsonNodeFactory'ies? A single global factory? A thread-local factory? No > factory but explicit JsonNode::new calls? > > Thanks in advance. > Best. > -- 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 post to this group, send email to [email protected]. For more options, visit https://groups.google.com/d/optout.
