JSON to Java: Generate POJOs Fast

Java's com.fasterxml.jackson.databind.ObjectMapper maps JSON to POJOs using field names or @JsonProperty annotations. Writing these classes by hand for large API responses is slow - a 15-field response with two nested objects becomes 80+ lines of boilerplate before you write any real logic. Here's how the mapping works and how to automate it.

JSON to Java Type Mapping

Use wrapper types (Integer vs int) when a field can be null. Primitives can't hold null, so null in JSON silently becomes 0 or false if you use primitives. That's the kind of bug that surfaces in production, not in tests.

Basic POJO Structure

Given this API response:

The Jackson-compatible POJO is:

Jackson can also use naming strategies to skip @JsonProperty annotations. Set SNAKE_CASE strategy and user_id maps to userId automatically. Explicit @JsonProperty is clearer though - if you rename userId to id in the class, the JSON key stays "userId" and nothing breaks.

Nested Objects

JSON objects inside objects become separate Java classes:

Each nested object gets its own class. The hierarchy mirrors the JSON structure exactly. For responses with 3-4 levels of nesting, that's 4-5 separate class files - which is why generators save real time.

Handling Null Fields

If a JSON field can be absent or null, use wrapper types and @JsonInclude:

@JsonInclude(NON_NULL) at the class level skips null fields when serializing back to JSON. Without it, you get "nickname": null in your output. Whether that's correct depends on your API contract.

For API clients that only read JSON, you almost never need to distinguish absent from null. A nullable reference type handles both cases.

Arrays and Lists

JSON arrays map to List:

Use List rather than arrays. Both work with Jackson, but List gives you the full collections API and avoids length checks.

Lombok Integration

Getters, setters, and constructors are half the boilerplate in Java POJOs. Lombok removes them:

@Data generates getters, setters, equals, hashCode, and toString. @NoArgsConstructor generates the no-arg constructor Jackson needs for deserialization. This is the standard pattern in Spring Boot projects - if your team already uses Lombok, apply it to every POJO.

Java Records (Java 16+)

Records are a better fit for immutable API response models:

Records auto-generate the constructor, accessors, equals, hashCode, and toString. Jackson 2.12+ supports records without extra configuration. If you're on Java 17+ (the current LTS), prefer records for response models you only read and never mutate.

Deserializing in Practice

TypeReference is necessary for generic types because Java's type erasure removes at runtime. Without it, Jackson doesn't know what to instantiate inside the list.

One annotation to add to every API client POJO: @JsonIgnoreProperties(ignoreUnknown = true). By default, Jackson throws UnrecognizedPropertyException if the JSON has fields your class doesn't have. APIs add fields over time. This annotation silently skips unknown ones:

Without it, a new field added upstream will break your deserialization. Add it by default to all API response classes.

Jackson Dependencies

For Maven:

For Gradle:

Spring Boot pulls Jackson in automatically via spring-boot-starter-web. For plain Java projects without Spring, add it explicitly.

Generating POJOs from JSON

For responses with many fields and nested objects, generating the initial scaffold saves significant time. Paste your API response into the JSON to Java converter and get all the classes with correct types and annotations ready to copy.

Validate your input first with JSON Validator if the API response might be malformed - invalid JSON produces incorrect class structures. For complex nested responses, use JSON Viewer to inspect the structure before generating.