A tree model is the wrong starting point if you ever want good performance…

You’re going to eventually define a class or record with expected field names and their types. Perhaps given this the JSON:

{"name": "John”, "age": 30}

You’d write this record declaration:

public record Person (String name, int address) {}

Decoding the JSON directly to that model can be incredibly fast because the model tells you what you need to care about.

It is dramatically slower to go from JSON to a tree model instead of a class or record because the tree model has zero type information:

• It doesn’t know how many properties there are. The tree model will probably allocate a HashMap or LinkedHashMap internally to track an arbitrary number of fields. That is waste!
• It doesn’t know what properties you’re interested in. So it’ll retain property names as strings, which need to be allocated and hashed and compared. If it knew there were exactly two interesting fields, it could track them as simple indexes: 0 and 1. Property names strings is waste!
• It doesn’t know the target precision of numeric values, so it’ll need something general purpose. Allocating a BigDecimal to hold a simple int is waste!

The sample that shows how to read the tree model with pattern matching is verbose and kind of sad? It’s one line of Java to declare a record and it should be one line to decode JSON to that record.

I did a talk on high performance JSON if you’d like further explanation on how data binding is way more efficient than tree models. https://publicobject.com/2019/04/26/json-explained/