Jackson و JSONJackson & JSON

Every program that talks to the outside world — exposing an API, calling another API, publishing to a queue, or just reading a config file — eventually has to turn a Java object into text, or the reverse. The lingua franca of that exchange is usually JSON, and in the Java world the tool of choice is Jackson. If you have ever written Spring Boot, then every time a controller returns an object, Jackson is quietly at work behind the scenes — whether you knew it or not.

We will take this step by step: first an analogy to grasp what "serialize" even means, then the technical term, then wire it to real code, and finally to interview questions. Don't rush — the goal is to understand this tool for good, not memorize it.

Part 0 — Three words you must understand from scratch

What do "serialize" and "deserialize" mean?

So we've pinned two technical words to one picture:

• Serialize: a live in-memory object → a flat text/byte string you can store or send. In Jackson-speak this is write or marshalling.
• Deserialize: that text/bytes → a live Java object again. In Jackson-speak this is read or unmarshalling.

What exactly is JSON?

JSON stands for JavaScript Object Notation, but today it has nothing to do with JavaScript and is the universal data-exchange language of the web. It has only a handful of data types, and that simplicity is its power:

{
  "id": 42,
  "name": "Ali",
  "active": true,
  "balance": 1250.75,
  "roles": ["admin", "editor"],
  "address": { "city": "Tehran", "zip": "12345" },
  "deletedAt": null
}

That's the entire grammar of JSON right there: objects ({} with key:value pairs), arrays ([]), strings (in "), numbers, booleans (true/false), and null. That's it. No classes, no dates, no custom types. Jackson's job is to bridge these few simple types to rich Java objects and back.

What does "data binding" mean?

When we say Jackson does "data binding," we mean it automatically binds JSON fields to the fields/methods of a Java class. You just declare the shape (a class/record); Jackson uses reflection to inspect the fields and maps them for you. That automatic binding is exactly what saves you from a thousand lines of manual glue code.

Part 1 — Meet Jackson

Jackson is not a single library — it's a family. You must know its three core modules, because their names come up everywhere:

In Maven you usually add only databind and the other two come transitively:

<dependency>
  <groupId>com.fasterxml.jackson.core</groupId>
  <artifactId>jackson-databind</artifactId>
  <version>2.20.0</version>
</dependency>

Two important lines: Jackson 2 and Jackson 3

As of mid-2026 there are two live version lines, and you should know both:

• Jackson 2.x — the established, widely used line. The latest is 2.20 (August 2025); Spring Boot 3 rides on it. groupId and Java package are both com.fasterxml.jackson.*. Minimum Java: 8.
• Jackson 3.0 — the next generation, which went GA in October 2025, with the 3.1 line following in 2026. Spring Boot 4 rides on it. Here the package was renamed to tools.jackson.* (so 2 and 3 can coexist), Java 17 is required, and ObjectMapper became immutable. Details in the last part.

Part 2 — ObjectMapper: Jackson's workhorse

ObjectMapper is the heart of Jackson. Almost everything starts here. Let's see the simplest scenario: a plain class (a so-called POJO, Plain Old Java Object — an unpretentious plain object).

import com.fasterxml.jackson.databind.ObjectMapper;

public class User {
    private long id;
    private String name;
    private boolean active;

    // Jackson needs getters/setters or field access for data binding
    public long getId() { return id; }
    public void setId(long id) { this.id = id; }
    public String getName() { return name; }
    public void setName(String name) { this.name = name; }
    public boolean isActive() { return active; }
    public void setActive(boolean active) { this.active = active; }
}

ObjectMapper mapper = new ObjectMapper();

// Serialize: object -> JSON string
User u = new User();
u.setId(42);
u.setName("Ali");
u.setActive(true);

String json = mapper.writeValueAsString(u);
// {"id":42,"name":"Ali","active":true}

// Deserialize: JSON string -> object
String input = "{\"id\":7,\"name\":\"Sara\",\"active\":false}";
User parsed = mapper.readValue(input, User.class);
System.out.println(parsed.getName()); // Sara

That's it. Two core methods handle 90% of your work: writeValueAsString(...) to write and readValue(...) to read. There are overloads too: writeValue(File/OutputStream, obj) writes straight to a file/stream, and readValue(File/InputStream/byte[], Class) reads from various sources.

The critical performance and thread-safety point

If you want a full safety guarantee plus a little more speed, Jackson has two fully immutable, thread-safe siblings you obtain from the mapper:

ObjectMapper mapper = new ObjectMapper();

// Build once, use infinitely — fully thread-safe
ObjectWriter writer = mapper.writerFor(User.class).withDefaultPrettyPrinter();
ObjectReader reader = mapper.readerFor(User.class);

String pretty = writer.writeValueAsString(u);
User back = reader.readValue(input);

Two features you'll need on day one

ObjectMapper mapper = new ObjectMapper();

// 1) If the JSON has a field your class doesn't — don't fail, ignore it
mapper.disable(DeserializationFeature.FAIL_ON_UNKNOWN_PROPERTIES);

// 2) Pretty, indented output (for debug/logs only; not in prod — it bloats size)
mapper.enable(SerializationFeature.INDENT_OUTPUT);

Part 3 — Three ways to work with JSON: streaming, tree, data-binding

This is one of the most important architectural decisions. Jackson offers three completely different styles for working with JSON, and choosing right is the difference between performance and readability.

1) Streaming API — low-level, fast, token-by-token

Here you work directly with JsonParser (reading) and JsonGenerator (writing). Jackson breaks JSON into a sequence of tokens (START_OBJECT, FIELD_NAME, VALUE_STRING, …) and you advance through them one at a time:

JsonFactory factory = new JsonFactory();

// Manual writing
StringWriter sw = new StringWriter();
try (JsonGenerator gen = factory.createGenerator(sw)) {
    gen.writeStartObject();
    gen.writeNumberField("id", 42);
    gen.writeStringField("name", "Ali");
    gen.writeEndObject();
}
// {"id":42,"name":"Ali"}

// Manual reading
try (JsonParser p = factory.createParser("{\"id\":42,\"name\":\"Ali\"}")) {
    while (p.nextToken() != JsonToken.END_OBJECT) {
        if (p.currentToken() == JsonToken.FIELD_NAME) {
            String field = p.currentName();
            p.nextToken(); // move onto the value
            if (field.equals("name")) {
                System.out.println("name = " + p.getText());
            }
        }
    }
}

When do you use this? When the data is very large (multi-gigabyte logs or export files) and you don't want to hold it all in memory, or when maximum throughput is critical. The price: verbose, error-prone code.

2) Tree Model — the whole JSON as a tree

Here Jackson reads the entire JSON into a JsonNode tree. Like the DOM for HTML. Use it when the structure is unknown or dynamic, or when you only want a few fields without defining a class:

ObjectMapper mapper = new ObjectMapper();
JsonNode root = mapper.readTree(input);

long id = root.get("id").asLong();
String city = root.path("address").path("city").asText("unknown"); // path is safer
boolean isAdmin = false;
for (JsonNode role : root.path("roles")) {
    if (role.asText().equals("admin")) isAdmin = true;
}

// Building an editable tree
ObjectNode out = mapper.createObjectNode();
out.put("ok", true);
out.putArray("items").add(1).add(2).add(3);

3) Data Binding — the most common case

Exactly what we saw in Part 2: bind JSON straight to a POJO/record. 95% of daily work is this. For generic types (like List<User>) you must use a TypeReference, otherwise Java's type erasure loses the element type:

// This does NOT do what you think — the inner type is lost
List<User> wrong = mapper.readValue(jsonArray, List.class); // List<LinkedHashMap>!

// The right way: TypeReference preserves the full type
List<User> users = mapper.readValue(jsonArray,
        new TypeReference<List<User>>() {});

Map<String, User> byName = mapper.readValue(jsonMap,
        new TypeReference<Map<String, User>>() {});

Comparison table

Part 4 — Core annotations: precise control over mapping

The real world is never tidy: the field name in JSON differs from the field name in Java, some fields shouldn't be serialized, you don't want nulls, and so on. Annotations are the control levers. Let's see the important ones in code:

public class Account {

    // The JSON field name differs from the Java name
    @JsonProperty("user_name")
    private String userName;

    // This field must never appear in JSON (neither on read nor write)
    @JsonIgnore
    private String passwordHash;

    // Several allowed input names when reading (output uses the primary name)
    @JsonAlias({"email", "mail", "emailAddress"})
    private String email;

    // Date format
    @JsonFormat(shape = JsonFormat.Shape.STRING, pattern = "yyyy-MM-dd")
    private LocalDate birthDate;

    // ... getters/setters
}

Let's categorize the important ones:

@JsonInclude — getting rid of nulls

By default, Jackson writes every field, even nulls. Often you don't want output full of "x": null:

@JsonInclude(JsonInclude.Include.NON_NULL) // only non-null fields
public class Response {
    public String data;
    public String error; // if null, it won't appear in the output at all
}

// or globally on the whole mapper:
mapper.setSerializationInclusion(JsonInclude.Include.NON_NULL);

Options: NON_NULL (drop nulls), NON_EMPTY (also drop empty strings/lists), NON_ABSENT (for empty Optional), NON_DEFAULT (drop default values).

@JsonCreator — when your constructor has arguments

If your class has no getters/setters and no no-arg constructor (e.g. it's an immutable object), Jackson doesn't know how to build it. With @JsonCreator you point it at the constructor, and with @JsonProperty you wire each argument to a JSON field:

public final class Point {
    private final int x;
    private final int y;

    @JsonCreator
    public Point(@JsonProperty("x") int x,
                 @JsonProperty("y") int y) {
        this.x = x;
        this.y = y;
    }
    public int getX() { return x; }
    public int getY() { return y; }
}

@JsonValue — clean enums

public enum Status {
    ACTIVE("A"), INACTIVE("I"), BANNED("B");

    private final String code;
    Status(String code) { this.code = code; }

    @JsonValue                         // write this short code in JSON
    public String getCode() { return code; }

    @JsonCreator                       // and read from that same code
    public static Status fromCode(String code) {
        for (Status s : values())
            if (s.code.equals(code)) return s;
        throw new IllegalArgumentException("bad code: " + code);
    }
}
// Status.ACTIVE  ->  "A"  (not "ACTIVE")

Part 5 — Dates and java.time: the source of half your headaches

Dates don't exist in JSON! (Remember? JSON only has number/string/boolean.) So Jackson has to decide how to write a LocalDateTime. And here lurks a classic trap.

{ "createdAt": [2026, 7, 20, 14, 30, 0] }

Why does this happen? Because Jackson 2 doesn't know java.time by default — you must register the JavaTimeModule and disable the notorious WRITE_DATES_AS_TIMESTAMPS feature:

ObjectMapper mapper = new ObjectMapper();
mapper.registerModule(new JavaTimeModule());               // teach it java.time
mapper.disable(SerializationFeature.WRITE_DATES_AS_TIMESTAMPS); // ISO-8601 strings, not numbers

// Since Jackson 2.10, the shorter way: auto-discover all modules
ObjectMapper m2 = JsonMapper.builder()
        .findAndAddModules()
        .disable(SerializationFeature.WRITE_DATES_AS_TIMESTAMPS)
        .build();

Correct output:

{ "createdAt": "2026-07-20T14:30:00" }

To control the format of a specific field, use @JsonFormat:

public class Event {
    @JsonFormat(shape = JsonFormat.Shape.STRING,
                pattern = "yyyy-MM-dd HH:mm:ss",
                timezone = "Asia/Tehran")
    private ZonedDateTime startsAt;
}

Part 6 — Records and modern Java

Since Java 14/16, records arrived: immutable, terse data classes. Good news: Jackson has supported records natively since version 2.12 (late 2020). So this just works, with no annotations:

public record UserDto(long id, String name, boolean active) {}

ObjectMapper mapper = new ObjectMapper();

String json = mapper.writeValueAsString(new UserDto(42, "Ali", true));
// {"id":42,"name":"Ali","active":true}

UserDto back = mapper.readValue(json, UserDto.class); // it works!

Why are records so clean with Jackson? Because a record has a canonical constructor and Jackson uses it directly — exactly like the @JsonCreator pattern from Part 4, but automatic. Records are ideal DTOs: immutable, thread-safe, no boilerplate.

public record UserDto(
    long id,
    @JsonProperty("full_name") String name,
    boolean active) {}

Part 7 — Custom serializers and deserializers

Sometimes Jackson's default behavior isn't enough: you want a specific type written a specific way — e.g. serialize a Money as the string "$12.50". That's where you write a custom serializer.

// Serializer: object -> JSON
public class MoneySerializer extends JsonSerializer<Money> {
    @Override
    public void serialize(Money value, JsonGenerator gen,
                          SerializerProvider sp) throws IOException {
        gen.writeString("$" + value.getAmount());
    }
}

// Deserializer: JSON -> object
public class MoneyDeserializer extends JsonDeserializer<Money> {
    @Override
    public Money deserialize(JsonParser p, DeserializationContext ctx)
            throws IOException {
        String raw = p.getText().replace("$", "");
        return new Money(new BigDecimal(raw));
    }
}

Now register them with a SimpleModule so they apply globally:

SimpleModule module = new SimpleModule();
module.addSerializer(Money.class, new MoneySerializer());
module.addDeserializer(Money.class, new MoneyDeserializer());

ObjectMapper mapper = JsonMapper.builder()
        .addModule(module)
        .build();

Or if you only want it for one field, put it right on the field:

public class Invoice {
    @JsonSerialize(using = MoneySerializer.class)
    @JsonDeserialize(using = MoneyDeserializer.class)
    private Money total;
}

Part 8 — Polymorphic deserialization and the security bomb

This is the most important security section of the whole chapter. Read it carefully; a senior interview will almost certainly ask about it.

The problem: polymorphism

Suppose you have a field of type Animal that could be a Dog or a Cat. When you serialize, only the fields go into JSON — but the actual type is lost. On the way back, how does Jackson know to build a Dog or a Cat?

The correct and safe way to solve it is the @JsonTypeInfo annotation, which puts an explicit "type tag" in the JSON:

@JsonTypeInfo(use = JsonTypeInfo.Id.NAME, property = "type")
@JsonSubTypes({
    @JsonSubTypes.Type(value = Dog.class, name = "dog"),
    @JsonSubTypes.Type(value = Cat.class, name = "cat")
})
public abstract class Animal { public String name; }

public class Dog extends Animal { public boolean goodBoy; }
public class Cat extends Animal { public int lives; }

The output now carries a type tag and is unambiguous:

{ "type": "dog", "name": "Rex", "goodBoy": true }

The key point: here you have explicitly, with a closed list (@JsonSubTypes), declared which types are allowed. Jackson will only build a Dog or a Cat, nothing else.

The bomb: Default Typing and gadget chains

Now suppose that instead of this closed list, you tell Jackson: "for any object, write the full Java class name into the JSON, and on read, build whatever class the JSON says." This is called default typing:

// DON'T do this with untrusted input
ObjectMapper mapper = new ObjectMapper();
mapper.enableDefaultTyping(); // deprecated and dangerous

The output looks something like this, carrying the fully-qualified class name inside the data itself:

["com.example.Dog", { "name": "Rex" }]

Why is this a security disaster?

This is precisely the origin of a long string of infamous jackson-databind CVEs — from CVE-2017-7525 (the first big wave) onward. For years the Jackson team played whack-a-mole with a blocklist of dangerous classes: every time a new gadget was found, a new CVE and a new release followed. But a blocklist is inherently losing, because there's always a next gadget.

The right way: PolymorphicTypeValidator and allowlist

From Jackson 2.10 the approach changed: enableDefaultTyping() was deprecated and replaced by activateDefaultTyping(PolymorphicTypeValidator, ...), which forces you to supply a type validator — i.e. an allowlist of permitted classes/packages:

// If you truly need default typing, at least restrict it
PolymorphicTypeValidator ptv = BasicPolymorphicTypeValidator.builder()
        .allowIfSubType("com.myapp.model.")  // only my own package
        .build();

ObjectMapper mapper = JsonMapper.builder()
        .activateDefaultTyping(ptv, DefaultTyping.NON_FINAL)
        .build();

Part 9 — Performance and best practices

Part 10 — Jackson 3: what changed?

If you're starting a new project or moving to Spring Boot 4, you should know these:

// Jackson 3 style — immutable builder
import tools.jackson.databind.json.JsonMapper;

JsonMapper mapper = JsonMapper.builder()
        .configure(SerializationFeature.INDENT_OUTPUT, true)
        .build();

String json = mapper.writeValueAsString(new UserDto(42, "Ali", true));

Interview questions

Sources: Jackson 3.0 GA (cowtowncoder), Migrating to Jackson 3, Jackson Polymorphic Deserialization CVE Criteria, CVE-2026-54512, Records support in Jackson 2.12.