JSON to Java Class — POJO, record, or Lombok with Jackson / Gson Annotations

Real-world use cases

• Type a Spring Boot REST response without hand-writing the model

  You're consuming a third-party API from a Spring service and the response has 25+ fields with snake_case keys. Curl it once, paste the JSON here, set the root name to `OrderResponse`, keep Jackson. Every `created_at`-style key gets a `@JsonProperty` so your `ObjectMapper` binds it, nested objects lift into their own classes, and the optional fields box correctly. Drop the output into `OrderResponse.java`, then `restTemplate.getForObject(url, OrderResponse.class)` returns a fully-typed object instead of a `Map<String, Object>` you have to cast your way through field by field.

• Generate immutable DTOs with Java records

  A teammate sends a sample request body for the `/orders` endpoint they're building. Paste it, name the root `CreateOrderRequest`, switch the type to `record`. You get a one-line, immutable DTO with value equality and a canonical constructor — no setters to accidentally mutate, no Lombok dependency, and Jackson deserializes records out of the box since 2.12. Paste the response sample too as a second record and both are committed before either of you writes the controller.

• Keep a Lombok codebase consistent

  Your project already leans on Lombok everywhere. Paste the payload, choose `Lombok @Data`, and you get `@Data`-annotated classes with the `lombok.Data` import — the getters, setters, `equals`, `hashCode`, and `toString` are all generated at compile time, so the source stays as short as the JSON it came from. The new model matches the house style your reviewers expect, with zero boilerplate to scroll past in the PR.

• Catch which fields are actually optional in a webhook

  A vendor's webhook sometimes includes `cancelled_at` and sometimes omits it. Log a handful of payloads, paste them as a JSON array, and the array-fold detection marks `cancelled_at` as missing in some elements — so it boxes to a wrapper type instead of a primitive that would silently read 0. In your handler a null check now cleanly distinguishes "cancelled" from "still active" instead of guessing whether a default value means the field was absent.

• Replace a Map<String, Object> with a real type

  Legacy code does `Map<String, Object> data = mapper.readValue(body, Map.class)` and reaches in with casts like `(String) data.get("id")`, losing every compile-time check. Capture one representative response, paste it, generate the class, and replace the map. Now `int`, `long`, and `double` are inferred per field and the compiler catches a renamed key at build time instead of a `ClassCastException` surfacing in prod.

Common pitfalls

• Pasting a single object and expecting some fields to be boxed (Integer instead of int). A single object has no missing-key signal, so every numeric field is required and stays primitive unless its value is literally null. Optional/boxing inference only kicks in across an array of objects where some elements carry a key and others don't. To explore optionality from one sample, wrap it as `[{...}]`.

• Leaving a money or precise-decimal field as `double`. The tool infers `double` for any fractional number, but `double` is binary floating point and will misrepresent values like 0.1 or a currency total. For money, hand-edit those fields to `BigDecimal` after generating — JSON carries no signal that a number needs exact base-10 precision.

• Deleting the @JsonProperty annotation and expecting binding to still work. The annotation is what maps `site_admin` (wire) to `siteAdmin` (field). Remove it and Jackson/Gson will look for a `siteAdmin` key that doesn't exist, leaving the field null. Either keep the annotation or configure a global naming strategy on your mapper instead.

• Choosing `record` on a pre-Java-16 project. Records are a Java 16 language feature (preview in 14–15). If your build targets Java 11 or 8, the generated `record` won't compile — pick POJO or Lombok for those targets.

Privacy