https://docs.spring.io/spring-framework/docs/6.0.0/reference/html/integration.html#rest-http-interface

I would like to have the default behavior (even without using of @NonNullApi or with @NonNullApi if that is impossible ) for parameters and return values is, respectively, neither to accept nor to produce null values and use @Nullable on a parameter or return value that can be null.

Comment From: sdeleuze

I think we should try to be consistent with null-handling in Spring MVC/WebFlux controllers.

For method parameters, that means HTTP interfaces should (if that's not already the case) leverage MethodParameter#isOptional which checks whether this method parameter is annotated with any variant of a Nullable in order to conceptually infer the value of the required annotation attribute of annotations like @RequestPart, @RequestParam, @RequestBody, etc.

For return values, I am not sure Spring MVC/WebFlux controllers are doing some special null-safety handling, so not sure something should be done in HTTP Interfaces.

@m-titov Would interpreting @Nullable on method parameters as required = false annotation attribute fit your need? Could you confirm it is currently not the case and provide a reproducer?

Comment From: m-titov

Hi @sdeleuze ,

@m-titov Would interpreting @Nullable on method parameters as required = false annotation attribute fit your need? Could you confirm it is currently not the case and provide a reproducer?

Yes, it seems Ok to me. But I would also like to be able to have (or at least to make) return values not null by default globally and to annotate with @Nullable those of them which are actually cound be null.

Comment From: sdeleuze

For this kind of need, you can maybe try to use bean validation.

Can you please provide a repro to ensure we need to do something for @Nullable handling on parameters?

Comment From: m-titov

For this kind of need, you can maybe try to use bean validation.

Well.. Then it would be inconsistent with spring data https://docs.spring.io/spring-data/data-jpa/reference/repositories/null-handling.html#repositories.nullability.annotations:~:text=%40Nullable%3A%20Used%20on%20a%20parameter%20or%20return%20value%20that%20can%20be%20null. where if we annotate the corresponding package with @NonNullApi, then only the method which returns value annotated with @Nullable can return null; otherwise, it throws an exception for null return value out of the box

Comment From: sdeleuze

Good point about Spring Data, more consistency would be welcomed between Spring Framework and Spring Data (but that has a wider scope than this issue).

@mp911de Could you please point me to the Spring Data code that performs null handling? I am especially interested in understanding how you manage package-level annotations, and if you support only Spring Framework null-safety annotations or if you implemented generic JSR 305 support.

Comment From: mp911de

The entry point to method invocation validation is at https://github.com/spring-projects/spring-data-commons/blob/main/src/main/java/org/springframework/data/repository/core/support/MethodInvocationValidator.java

We support Spring‘s annotations, JSR 305 (as add-on if on the class path) and Kotlin nullability metadata via Kotlin reflection.

It would make sense to move our code into Framework at some point.

Comment From: sdeleuze

After more thoughts and discussion with @jhoeller, it appears clearly that we need to differentiate optionality as defined in MethodParameter#isOptional (what Spring Framework programming model supports) and language level nullability (what Spring Data programming model supports). For the scope of this issue, let's stick to the former and plan it for 6.2.

@mp911de I will reach you once I have more news on the future of null-safety at Java level and to discuss its potential impact at programming model level, and how we could unify such handling portfolio wide.

Comment From: OlgaMaciaszek

Will work on it.

Comment From: snicoll

@OlgaMaciaszek how is it going?

Comment From: OlgaMaciaszek

@snicoll Thanks for the reminder. Will submit the PR by the end of next week. Let me know if that's fine or if you would prefer me to reschedule things in order to get this in earlier?

Comment From: snicoll

Closing in favor of PR #33339 - Thanks @OlgaMaciaszek!