Resolving Incorrect Boolean Mapping in Jackson ObjectMapper: When All Values Are False

When converting between Java objects — such as entities, DTOs, or database objects — developers often rely on Jackson’s ObjectMapper for its convenience and flexibility. However, subtle differences in field naming conventions can cause unexpected issues, especially with boolean fields.

A common problem appears when using:

ObjectMapper objectMapper = new ObjectMapper();
return objectMapper.convertValue(this, BankDto.class);

Even though the database contains both true and false values, the resulting DTO shows only false values for the field — for example, oauthEnabled.

This article explores why this happens, how Jackson handles naming conventions, and how to properly fix it.

The Scenario

Let’s assume the following setup:

// In BankEntity.java
private boolean oauth_Enabled;

and

// In BankDbo.java
private boolean oauthEnabled;

Your mapper converts one class to another using:

public BankDto toDto() {
    ObjectMapper objectMapper = new ObjectMapper();
    return objectMapper.convertValue(this, BankDto.class);
}

But when you inspect the resulting BankDto, every instance has:

oauthEnabled = false

—even though the database clearly contains true values.

The Root Cause: Naming Conventions and Bean Introspection

Jackson follows JavaBean property naming conventions to discover fields and map their values.
That means for a property oauthEnabled, Jackson expects corresponding getter and setter methods:

public boolean isOauthEnabled();
public void setOauthEnabled(boolean oauthEnabled);

However, if the field name includes underscores, such as oauth_Enabled, Jackson treats it as a different property altogether (oauth_Enabled ≠ oauthEnabled).
So during the conversion, Jackson doesn’t find a matching source field for the target field name, and the default boolean value false is applied.

Verifying the Behavior

Let’s quickly demonstrate the mismatch.

class BankEntity {
    public boolean oauth_Enabled = true;
}

class BankDto {
    public boolean oauthEnabled;
}

ObjectMapper objectMapper = new ObjectMapper();
BankDto dto = objectMapper.convertValue(new BankEntity(), BankDto.class);
System.out.println(dto.oauthEnabled); // prints false

The reason: ObjectMapper cannot infer that oauth_Enabled and oauthEnabled are the same property.

Solution 1: Align Field Names

The most straightforward solution is to use consistent naming across all models:

// In both Entity and DTO
private boolean oauthEnabled;

This ensures automatic mapping by Jackson without additional configuration.

Solution 2: Use @JsonProperty Annotation

If you must keep different field names (e.g., due to legacy database column mappings), you can use the @JsonProperty annotation to explicitly define how Jackson should map fields.

public class BankEntity {
    @JsonProperty("oauthEnabled")
    private boolean oauth_Enabled;
}

or the reverse:

public class BankDto {
    @JsonProperty("oauth_Enabled")
    private boolean oauthEnabled;
}

This tells Jackson to treat both fields as equivalent when converting.

Solution 3: Apply a Naming Strategy

Jackson also provides configurable naming strategies for handling underscores, camel case, and other conventions.
For example, you can enable snake_case property mapping:

ObjectMapper objectMapper = new ObjectMapper();
objectMapper.setPropertyNamingStrategy(PropertyNamingStrategies.SNAKE_CASE);

With this configuration:

• oauth_Enabled (snake case)
• automatically maps to oauthEnabled (camel case)

This is useful when you have multiple mismatched fields across your domain models.

Solution 4: Manual Mapping (When Precision Matters)

For total control, consider writing a custom mapper:

public BankDto toDto() {
    BankDto dto = new BankDto();
    dto.setOauthEnabled(this.oauth_Enabled);
    // map other fields manually
    return dto;
}

While more verbose, this approach eliminates ambiguity and can include transformation logic (e.g., data validation or conversion).

Best Practices to Avoid Similar Issues

1. Use consistent naming conventions — stick with camelCase across all classes.
2. Avoid underscores in Java field names. Use @Column(name = "oauth_enabled") for DB mapping instead.
3. Leverage Jackson annotations when you can’t control legacy naming.
4. Validate conversions with unit tests to ensure no silent data loss occurs.
5. Reuse a configured ObjectMapper instance instead of creating new ones — this keeps your mapping rules consistent.

Conclusion

When ObjectMapper.convertValue() returns incorrect boolean values — especially all false — it’s almost always a naming convention issue. Jackson relies heavily on matching property names according to JavaBean rules.

To fix the problem:

• Align your variable names (oauthEnabled ↔ oauthEnabled),
• or use @JsonProperty annotations,
• or apply a consistent naming strategy.

By doing so, you’ll ensure accurate data transfer between your entities, DTOs, and database objects — and prevent hidden mapping bugs that can affect your application logic.