Sébastien Deleuze opened SPR-15540 and commented

The proposal brought by this issue is to make nullability of return values and parameters of Spring Framework API explicit via annotations, and leverage this information in Kotlin user Spring projects.

More details can be found in these 2 Square blog posts Rolling out @Nullable and Non-null is the default.

If at some points @ParametersAreNonnullByDefault is supported at package level, it seems it could be possible to add @Nullable annotation only on nullable parameter and return values without bloating our code source with non-nullability annotations.

Notice that the com.google.code.findbugs:jsr305 dependency used is applied with a provided scope which seems to be enough to make it taken in account by Kotlin (without that Kotlin consider Java nullability as unknown). We need to check this would not create some classloader related issues.

Reference URL: https://youtrack.jetbrains.com/issue/KT-10942

Issue Links:

• DATACASS-459 Adopt to changed AnnotationUtils.getValue(…) behavior
• DATAJPA-1131 Adopt to changed AnnotationUtils.getValue(…) behavior
• DATAMONGO-1710 Adopt to changed AnnotationUtils.getValue(…) and OperatorNode.getRightOperand() behavior
• DATASOLR-396 Adopt to changed AnnotationUtils.getValue(…) behavior
• BeanNotOfRequiredTypeException (NullBean instead of null) when calling ApplicationContext.getBean(name, type) [SPR-16342] #20889 BeanNotOfRequiredTypeException (NullBean instead of null) when calling ApplicationContext.getBean(name, type)
• NPE in AnnotationUtils.getValue [SPR-15642] #20201 NPE in AnnotationUtils.getValue
• Setting user header on CONNECT message stopped working [SPR-15822] #20377 Setting user header on CONNECT message stopped working
• AbstractMessageSource does not properly interact with DelegatingMessageSource parent [SPR-16047] #20596 AbstractMessageSource does not properly interact with DelegatingMessageSource parent
• Null path after UriComponents.normalize() results in NullPointerException [SPR-16364] #20911 Null path after UriComponents.normalize() results in NullPointerException
• Inconsistent @Nullable on AbstractDestinationResolvingMessagingTemplate [SPR-15670] #20229 Inconsistent @Nullable on AbstractDestinationResolvingMessagingTemplate
• AnnotationAwareOrderComparator doesn't handle null values anymore [SPR-15823] #20378 AnnotationAwareOrderComparator doesn't handle null values anymore
• Fix overridden methods nullability [SPR-15869] #20424 Fix overridden methods nullability
• AbstractMessageSource does not support null as default message anymore [SPR-16127] #20675 AbstractMessageSource does not support null as default message anymore
• Nullability inconsistency in DataAccessUtils requiredSingleResult vs requiredUniqueResult [SPR-16225] #20773 Nullability inconsistency in DataAccessUtils requiredSingleResult vs requiredUniqueResult
• *Utils.find### to return Optional [SPR-17484] #22016 *Utils.find### to return Optional
• BeanDefinitionBuilder method arguments not annotated with @Nullable [SPR-15841] #20396 BeanDefinitionBuilder method arguments not annotated with @Nullable
• STOMP SEND should not map to @SubscribeMapping methods [SPR-16109] #20657 STOMP SEND should not map to @SubscribeMapping methods
• Consistent use of Collection.toArray with zero-sized array argument [SPR-16523] #21066 Consistent use of Collection.toArray with zero-sized array argument
• Decouple o.s.w.reactive.result.view.UrlBasedViewResolver from ApplicationContext [SPR-15219] #19784 Decouple o.s.w.reactive.result.view.UrlBasedViewResolver from ApplicationContext
• Revisit java.util.Optional declarations in reactive API signatures [SPR-15576] #20135 Revisit java.util.Optional declarations in reactive API signatures
• Extend null-safety to field level [SPR-15720] #20276 Extend null-safety to field level
• Revisit nullability annotations towards GA [SPR-15756] #20311 Revisit nullability annotations towards GA
• Backport selected refinements from the nullability efforts in 5.0 [SPR-15656] #20215 Backport selected refinements from the nullability efforts in 5.0
• Make getters and setters null-safety consistent [SPR-15792] #20347 Make getters and setters null-safety consistent

6 votes, 5 watchers