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

[spring-projects-issues]

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:

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

Referenced from: commits ec345bf

1 votes, 4 watchers

[spring-projects-issues]

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.