Assuming a form backing object:

class Form {

  private final LocalDate date;
  private final LocalTime time;

  public Form(LocalDate date, LocalTime time) {
    this.date = date;
    this.time = time;
  }

  // Getters omitted
}

and a controller method

class FormController {

  @PostMapping("/form")
  String postForm(@ModelAttribute Form form, BindingResult result) {
    …
  }
}

If the there's a binding error for one of the components of Form, form will be null which is unexpected as the binding invalidly assumes that Form is not able to deal with null values for its components.

In contrast to binding via setters, it's not really possible to use the partially bound instance to redisplay the form even partially bound. I've also tried to explicitly annotate the constructor arguments with @Nullable but that doesn't seem to change anything.

Comment From: rstoyanchev

This is closely related to #22600 and the two should be considered together, so I've scheduled this tentatively for 5.3 M1 as well.

The proposal here is to try and invoke the constructor anyway with null in place of arguments for which binding failed. If the constructor can deal with those nulls, then the benefit is that the model attribute can contain the partial input at least. This would be consistent with how data binding works via setters, and looking at the implementation, we already accumulate all binding errors so it's not too far off.

The trouble is that we don't know how the constructor deals with null values. It could be a problem if it doesn't work well with null values and it doesn't assert them. On the other hand for an object that's used in data binding, the absence of certain values should be expected at least. So I tend to think this does make sense.