JSON to Java

A Java POJO for a JSON payload is mostly boilerplate: a private field, a getter, and a setter per key. This generates all three, plus the Jackson @JsonProperty for keys that are not valid Java identifiers, with nested objects as their own classes and java.util.List imported only when an array actually appears.

The boxing rules are the part worth reading, because Java is the one language here where the type system lets absence and zero become the same value:

• longA required integer. Primitive, because it is always present — and long rather than int so a large id does not overflow.
• LongAn optional or nullable integer. The boxed type can hold null; a primitive would silently read a missing field as 0.
• doubleFractional numbers, boxed to Double when optional. Use BigDecimal for money — double cannot represent 0.1 exactly.
• booleanBooleans, boxed to Boolean when optional. A missing flag defaulting to false is the classic version of this bug.
• ObjectA field that was null in every record. Jackson will hand you a Map or a List at runtime, so narrow it once you have a populated sample.

Why is my count a Long here but a long elsewhere?

Because a primitive cannot hold absence. Where the sample shows a field is optional or sometimes null, the boxed type is used so the missing case stays distinguishable — with long it would arrive as 0, and nothing downstream could tell that apart from a real zero.

Why full getters and setters instead of Lombok?

The output has to compile in a project that has never heard of Lombok, and @Data pasted into a codebase without the annotation processor fails in a way that is genuinely confusing to debug. Deleting thirty lines of accessors and adding one annotation takes a moment; the reverse does not.

Could these be records?

On Java 16 and up, yes, and Jackson supports them from 2.12 — a record is a better fit for a decoded response, being immutable with value equality. Classes are generated because they compile on Java 8, which is still what a great many projects target. Converting a POJO to a record is mechanical; going the other way to support an older JDK is not.

Does this need @JsonIgnoreProperties?

It does not use it, but you may want it. Jackson fails by default on a key the class does not declare, so the day the API adds a field, deserialisation throws. @JsonIgnoreProperties(ignoreUnknown = true) on the class is the usual fix, and the usual reason a generated POJO breaks weeks after it was generated.

How are optional fields decided?

Every record in an array is inspected, not just the first. A field that appears in some records and not others is typed as optional, and a value that is sometimes null widens accordingly. Generators that read only the first element get this wrong on exactly the payloads where it matters.

What happens to a key that is a reserved word?

It is renamed to something legal in the target language, and where the language supports it, an annotation records the original JSON key so serialisation still round-trips.