Map to snake case while using a builder

You can use @JsonNaming(PropertyNamingStrategy.SnakeCaseStrategy.class) annotation.

Work with Project Lombok as well.

For example,

@Getter
@Builder
@JsonNaming(PropertyNamingStrategy.SnakeCaseStrategy.class)
public class YourDto {
    private final String myBanner;

    public YourDto(@JsonProperty("myBanner")
                   @JsonAlias("my_banner") String myBanner) {
        this.myBanner = myBanner;
    }
}

Above class can de-serialize following JSON,

{   
    "myBanner": "My own banner.."
}

And serialize to following JSON

{
    "my_banner": "My own banner.."
}

TL;DR: Extend Jackson's PropertyNamingStrategy to translate in both directions differently.

This approach keeps your target-classes (e.g. Layout) untouched (no constructor added, no fields annotated). See "Example" to copy from.

Issues

You are mixing a lot of configuration options here:

• PropertyNamingStrategy.CAMEL_CASE_TO_LOWER_CASE_WITH_UNDERSCORES
• @JsonProperty
• @JsonDeserialize(builder = Layout.LayoutBuilder.class)

1. PropertyNamingStrategy works bidirectional

The PropertyNamingStrategy.CAMEL_CASE_TO_LOWER_CASE_WITH_UNDERSCORES is deprecated since version 2.7 and was replaced by SNAKE_CASE.

⚠️ It might also be misconceived as a bidirectional translation from JSON input fields in "camelCase" to JSON output fields in "snake_case".

But it actually applies this property-name translation from and to SNAKE_CASE for both - deserialization (JSON input) and serialization (JSON output).

So in your first attempt (with builder but without @JsonProperty) it does not read the "camelCase" input because expecting "snake_case", as previously configured on objectMapper

2. JsonProperty overrules PropertyNamingStrategy

In your second attempt (with @JsonProperty("camelCase")) it does read the "camelCase" but also writes "camelCase", because the field-annotation overrides the SNAKE_CASE naming-strategy previously configured on objectMapper.

See similar issue: Lombok with Jackson Deserializer from camelCase

3. Immutable requires a builder to deserialize

Immutable means the fields are final and can't work with setter-deserialization. Only a constructor will work. Thus you decided for Lomboks @Builder together with Jackson's @Deserialize(builder = Layout.LayoutBuilder.class).

Which keeps the class definition simple and consisting only of a field list.

Since the builder code generated by Lombok uses original field-names for build-methods and constructor-parameters, any fields annotated using @JsonProperty and different names would not be considered with those different names for deserialization.

To define a separate constructor for deserialization (with @JsonProperty annotated parameters) is cumbersome and means extra effort for maintenance. That's my concern with rai's answer.

Solving the Property-Naming issue

So you have to get the best of both worlds.

You could extend class PropertyNamingStrategy to have different naming-strategies for deserialization and serialization of a single class.

In a simple case override these methods:

• nameForGetterMethod to use snake_case for serializing to JSON ooutput
• nameForSetterMethod to use camelCase for deserializing from JSON input

Whereas both mutable and immutable classes use getters for serialization, the setter deserialization only applies to mutable classes.

For immutable classes and constructor-based deserialization (e.g. using the builder-pattern like defined with Lombok's @Builder) you can override the method:

• nameForConstructorParameter to use camelCase to deserialize from JSON input (e.g. into final fields)

Then annotate the target-class with @JsonNaming

Example

For example when your extended naming-strategy is:

public class CamelToSnakeStrategy extends PropertyNamingStrategy {

    @Override
    public String nameForField(MapperConfig<?> config, AnnotatedField field, String defaultName) {
        return defaultName;  // no translation
    }

    @Override
    public String nameForGetterMethod(MapperConfig<?> config, AnnotatedMethod method, String defaultName) {
        return PropertyNamingStrategy.SNAKE_CASE.translate(defaultName);
    }

    @Override
    public String nameForSetterMethod(MapperConfig<?> config, AnnotatedMethod method, String defaultName) {
        return PropertyNamingStrategy.LOWER_CAMEL_CASE.translate(defaultName);
    }

    @Override
    public String nameForConstructorParameter(MapperConfig<?> config, AnnotatedParameter ctorParam,
            String defaultName) {
        return PropertyNamingStrategy.LOWER_CAMEL_CASE.translate(defaultName);
    }
}

Then annotate your target bean with this @JsonNaming strategy:

@JsonNaming(CamelToSnakeStrategy.class) // use different cased naming: camel for in / snake for out
@JsonInclude(JsonInclude.Include.NON_NULL)
@JsonDeserialize(builder = Layout.LayoutBuilder.class)
@Builder
@Getter
public class Layout {
   
    // property default-name is translated 
    private final String myBanner;
}

You could also configure this naming-strategy in a module or at your (global) ObjectMapper:

objectMapper.setPropertyNamingStrategy(CamelToSnakeStrategy.class);

Solving the Builder-Deserialization issue

When deserializing immutable objects, this means fields are final to deny state-modification. Hence setters are no valid operation and only constructors (or builder) can be used to create instances.

See Deserialize Immutable Objects with Jackson.

This means for the naming-strategies:

• constructors used for deserialization; apply naming-strategy to constructor-parameters
• getters used for serialization; apply specific naming-strategy to getters

Lombok and Jackson

See related:

• @Jacksonized
• Best practices on using Jackson and Lombok - DEV Community
• Lombok Builder with Jackson - THE CURIOUS DEVELOPER

See also related questions:

• Using Jackson to deserialize with Lombok builder
• Jackson + Builder Pattern?
• how to globally define the naming convention with Jackson