AFAIK, @Data generates a @NoArgsConstructor, which is just wrong. Actually, @Data is wrong per se, as it's meant for mutable classes; @Value would be better, but it can't deal with the super constructor either.

So remove @Data, add @Getter, @EqualsAndHashCode, @ToString and whatever you need. Don't forget to add callSuper=true in the subclass.

This is effectively the constructor that Lombok should be constructing and invoking on the SuperBuilder.build() operation.

public Child(
    final String userId,
    final Instant requestingTime,
    final Instant beginningDate,
    final Instant endingDate,
    final Collection<String> fields) {

    super(userId, requestingTime);
    this.beginningDate = beginningDate;
    this.endingDate = endingDate;
    this.fields= fields;
}

No, that's not how SuperBuilder works. This is actually Lombok can't do as it can't see the super fields. Instead, the builder uses something like

public Child(ChildBuilder b) {    
    super(b);
    this.beginningDate = b.beginningDate;
    this.endingDate = b.endingDate;
    this.fields= b.fields;
}

You can believe what Jan Rieke says, he wrote it.

Updated 2018-11-10: Lombok 1.18.4 released

Updated 2020-10-18: Lombok 1.18.16 released

Lombok 1.18.16 contains the new @Jacksonized annotation. With it, you can simply write:

@JsonTypeInfo(use = JsonTypeInfo.Id.NAME, include = JsonTypeInfo.As.EXISTING_PROPERTY, property = "type")
@JsonSubTypes({
  @JsonSubTypes.Type(value = SubA.class),
  @JsonSubTypes.Type(value = AnotherSub.class)
})
@Jacksonized
@SuperBuilder
// more annotations...
public abstract class AbstractA {

    @JsonProperty
    protected final String superProperty;
}

@Jacksonized
@SuperBuilder
@JsonTypeName("SubA")
// more annotations...
public class SubA extends AbstractA {

    @JsonProperty
    private final String fieldA;
}

This will automatically insert all necessary Jackson annotations and do some adjustments to the generated builder. No need to customized anymore.

For earlier Lombok versions between 1.18.4 and 1.18.12, this is the way to go:

For Lombok's @Builder and @SuperBuilder to work with Jackson, you have to add the builder class header manually and place a @JsonPOJOBuilder(withPrefix="") on it. Lombok will then generate only the remainder of the builder class. This is necessary because Jackson's default is that the builder's setter methods have "with" as prefix, but Lombok's builders don't have any prefix (and Lombok is not and will probably never be configurable in this regard).

When @SuperBuilder was introduced in Lombok 1.18.2, it was not customizable (i.e., you could not manually add the builder class header). As a result, using @SuperBuilder with Jackson was not easily possible.

This changed with Lombok 1.18.4 (see this pull request): @SuperBuilder is now (at least partially) customizable, and this allows us to add the annotation. Beware that the code generated by @SuperBuilder is quite complex and heavily loaded with generics. To avoid accidentally messing up the code, you should have a look at the delombok output and copy/paste the class header from there. Here, you need add the builder implementation class header and put the annotation on it:

@JsonPOJOBuilder(withPrefix="")
static final class SubABuilderImpl extends SubABuilder<SubA, SubABuilderImpl> {
}

Note that you have to broaden the visibility of SubABuilderImpl to at least package-private.

The @JsonDeserialize annotation must also refer to the builder implementation class, not the abstract builder:

@JsonDeserialize(builder = SubA.SubABuilderImpl.class)

In fact, as Hossein Nasr already explained, Lombok cannot know whether there are subclasses that do not have toBuilder=true.

Lombok could require all direct subclasses of an abstract class to also use toBuilder by adding an abstract toBuilder() method on the abstract class. However, there may be use-cases where subclasses should not have a toBuilder (although I haven't seen any good examples of those). Furthermore, indirect subclasses may still lack the toBuilder feature. Therefore, lombok does not enforce toBuilder on subclasses of abstract classes.

Good news is that you can easily work around it in your case (only direct subclasses) by adding the abstract toBuilder() method to your abstract class Parent manually:

@SuperBuilder(toBuilder = true)
public abstract class Parent {
    public abstract ParentBuilder<?, ?> toBuilder();
}

With this change, your copy method compiles and works as expected.

If you also have indirect subclasses, you have to find other means to ensure they also have @SuperBuilder(toBuilder = true). If those would not have this annotation, you may experience strange behavior (e.g. calling copy() will instantiate a different class).

Disclaimer: I implemented the @SuperBuilder feature.

You shouldn't mix lombok @Builder with static inner Builder class. If it is possible to get rid of Builder class, the next code should work.

RequestMessage:

@Getter
@ToString
@EqualsAndHashCode(callSuper = true)
@SuperBuilder(toBuilder = true)
@AllArgsConstructor(access = AccessLevel.PRIVATE)
public class RequestMessage extends MyDTO {
    private final String name;

    @Override
    public String emitSerializedPayload() throws JsonProcessingException {
    return null;
    }
    public RequestMessage(String myAccountId, String name) {
        super(myAccountId);
        this.name = name;
}
}

MyDTO:

@Data
@SuperBuilder(toBuilder = true)
public abstract class MyDTO implements Serializable {
    @JsonIgnore private final ObjectMapper objectMapper = new ObjectMapper();
    protected String myAccountId;

    protected MyDTO() {}

    public MyDTO(String myAccountId) {
       this.myAccountId = myAccountId;
    }

    public static int hashCode(Object... objects) {
        return Arrays.deepHashCode(objects);
    }

    public static boolean equal(Object o1, Object o2) {
        // implementation of equals method
        return false;
    }
    public abstract String emitSerializedPayload() throws JsonProcessingException;
}

Test:

@Test
void name() {
    String myName = "myName";
    String myAccountId = "myAccountId";
    var request = RequestMessage.builder().name(myName).myAccountId(myAccountId).build();
    System.out.println("request = " + request);
    RequestMessage requestMessage = new RequestMessage(myAccountId, myName);
}
    

Customizing @SuperBuilder only works in more recent lombok version; you should always use the most recent one, which is v1.18.22 at the time of the writing of this answer.

With that version, customizing a @SuperBuilder constructor is possible. However, you are using code as a basis for your constructor that has been delomboked with v1.18.8. That does not work any more with current lombok versions. lombok v1.18.10 introduced that the actual field value for @Default fields are stored in the builder in fields like fieldName$value, not simply fieldName.

Thus, your customized constructor has to look as follows:

protected ApplicationUser(final ApplicationUserBuilder<?, ?> b) {
    super(b);
    this.application = b.application;
    if (b.groups$set) this.setGroups(b.groups$value);
    else this.setGroups(ApplicationUser.$default$groups());
}