Introduction

When a class comes from a library, generated code, or a shared module you cannot edit, you cannot add Jackson annotations directly to it. The standard Jackson answer is to attach annotations externally with a mix-in, which lets your ObjectMapper behave as though the original class had been annotated.

Use a Mix-in to Ignore a Property

Suppose you receive a third-party type that contains a field you do not want in JSON output.

1public class ExternalUser {
2    private final String username;
3    private final String passwordHash;
4
5    public ExternalUser(String username, String passwordHash) {
6        this.username = username;
7        this.passwordHash = passwordHash;
8    }
9
10    public String getUsername() {
11        return username;
12    }
13
14    public String getPasswordHash() {
15        return passwordHash;
16    }
17}

If you owned the class, you could place @JsonIgnore on getPasswordHash. Since you do not, create an abstract mix-in instead.

1import com.fasterxml.jackson.annotation.JsonIgnore;
2
3abstract class ExternalUserMixin {
4    @JsonIgnore
5    abstract String getPasswordHash();
6}

Now register that mix-in on the mapper you actually use.

1import com.fasterxml.jackson.databind.ObjectMapper;
2
3public class Demo {
4    public static void main(String[] args) throws Exception {
5        ObjectMapper mapper = new ObjectMapper();
6        mapper.addMixIn(ExternalUser.class, ExternalUserMixin.class);
7
8        ExternalUser user = new ExternalUser("mina", "secret-hash");
9        System.out.println(mapper.writeValueAsString(user));
10    }
11}

The serialized JSON contains username, but not passwordHash.

Ignore Several Properties at Once

If you need to exclude multiple properties, a class-level ignore annotation is often shorter.

1import com.fasterxml.jackson.annotation.JsonIgnoreProperties;
2
3@JsonIgnoreProperties({"passwordHash", "internalToken"})
4abstract class ExternalUserMixin {
5}

That approach is convenient when the property names are stable and you do not need method-level control.

Serialization and Deserialization Are Different Questions

Be precise about what “ignore” means. Sometimes the requirement is:

• do not serialize the property
• do not deserialize the property
• do not do either

A mix-in with @JsonIgnore often affects both directions. If you need asymmetric behavior, consider @JsonProperty(access = JsonProperty.Access.WRITE_ONLY) or READ_ONLY, again through a mix-in if necessary.

1import com.fasterxml.jackson.annotation.JsonProperty;
2
3abstract class ExternalUserMixin {
4    @JsonProperty(access = JsonProperty.Access.WRITE_ONLY)
5    abstract String getPasswordHash();
6}

That kind of detail matters when you want to accept a field from input but never expose it in output.

When a Custom Serializer Is the Better Tool

A mix-in is the cleanest answer when the change is annotation-like. If you need to reshape the JSON entirely, a custom serializer is more appropriate.

1import com.fasterxml.jackson.core.JsonGenerator;
2import com.fasterxml.jackson.databind.JsonSerializer;
3import com.fasterxml.jackson.databind.SerializerProvider;
4import java.io.IOException;
5
6class ExternalUserSerializer extends JsonSerializer<ExternalUser> {
7    @Override
8    public void serialize(ExternalUser value, JsonGenerator gen, SerializerProvider serializers) throws IOException {
9        gen.writeStartObject();
10        gen.writeStringField("username", value.getUsername());
11        gen.writeEndObject();
12    }
13}

That is more code, so do not reach for it unless you really need full output control.

Scope the Configuration Carefully

Mix-ins are attached to an ObjectMapper, not to the class globally. That is good because it keeps behavior scoped, but it also means you must register the mix-in on the mapper used by your application path. In larger systems, a mix-in can appear to “not work” simply because a different mapper instance handled serialization.

Common Pitfalls

• Creating the mix-in correctly but registering it on the wrong ObjectMapper or not registering it at all.
• Using @JsonIgnoreProperties(ignoreUnknown = true) when the real goal is to ignore a known property on the target class.
• Reaching for a custom serializer when a simple mix-in would solve the problem with less code.
• Forgetting to think about whether the property should be ignored for serialization, deserialization, or both.
• Depending on property names that may change across library versions without tests to catch the break.

Summary

• Jackson mix-ins let you apply ignore annotations to classes you cannot modify.
• Use method-level @JsonIgnore for one property or class-level @JsonIgnoreProperties for several.
• Register the mix-in on the mapper that actually performs JSON conversion.
• Use property access settings when you need different read and write behavior.
• Use a custom serializer only when you need more than an annotation-style override.