Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Revisit handling of missing fields (without default values) for immutable data classes [SPR-15877] #20432

spring-issuemaster opened this issue Aug 18, 2017 · 1 comment


Copy link

commented Aug 18, 2017

Juergen Hoeller opened SPR-15877 and commented

Following up on #20426 and #20101, there is still a case to be revisited: namely missing fields (without default values provided by Kotlin) which we currently inject as a null value. While this can be acceptable for object types, it leads to an IllegalArgumentException on construction for primitive types which is definitely worth improving. We could also reject such missing fields upfront if there are no default values or optional declarations for them.

Also, the WebFlux ModelAttributeMethodArgumentResolver needs to catch up around all of those RC4 refinements eventually.

Affects: 5.0 RC3

Issue Links:

  • #19763 Data binding with immutable objects (Kotlin / Lombok / @ConstructorProperties)
  • #20232 Kotlin class instantiation with optional parameters and default values
  • #20101 BindingResult support for constructor argument mismatch on immutable data object
  • #20402 Add support for Kotlin autowired constructor with optional parameters
  • #20426 Immutable object constructor arguments not considering WebDataBinder's FIELD_MARKER_PREFIX
  • #20994 Cannot create BindStatus for valid field on immutable form object in case of bind errors
  • #20569 Streamline and reduce Kotlin delegates

Referenced from: commits ec345bf

1 votes, 4 watchers


This comment has been minimized.

Copy link
Collaborator Author

commented Sep 27, 2017

Juergen Hoeller commented

We're sending null values through type conversion now for proper detection of primitive mismatches and also for java.util.Optional support now... but only for regular parameters, not for Kotlin's optional parameters which we're explicitly detecting there.

We also have a KotlinDetector delegate in org.springframework.core now, for the common detection of Kotlin's presence and for identifying Kotlin types and Kotlin's optional parameters.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
None yet
2 participants
You can’t perform that action at this time.