Nullability constraints are typically inherited for methods that specify e.g. @Nullable on the interface level.

Do you have further pointers regarding that issue towards how Kotlin considers nullability annotation rules?

Paging @sdeleuze

@mp911de I tried it based on your comments. In Java, as you said, it inherits the @Nullable annotation specified on the interface level, but in Kotlin it is not.

Here's my situation:
스크린샷 2021年12月10日 오전 1 18 55

Thanks a lot, that's quite interesting and likely a subject to happen in other places as well that use nullability annotations on interfaces.

Seems that this is a general issue: spring-projects/spring-framework#20424

I understand that this is a general issue that can happen in other places as well.

For one more reason, for code consistency, I think it's better to add @Nullable annotation to RedisTemplate#execute(SessionCallback) method. The RedisTemplate#execute(RedisCallback) method, like the RedisTemplate#execute(SessionCallback) method, is annotated with @Nullable at the interface level, but is annotated with @Nullable once again. I think this difference can be confusing. I wonder what you think!

I wonder why Kotlin considers JSR-305 so much different than Java tooling does. Regardless, if a method is @Nullable on the interface level, then it is expected to adhere to that contract in the implementation method. The only exception is if the implementation method is annotated with @NonNull. The ...Operations interfaces are designed to be the entry-point and to not use the concrete implementation directly unless necessary.

The annotation on <T> T execute(RedisCallback<T> action) is an oversight and comes from the initial introduction of nullability annotations. <T> T execute(RedisCallback<T> action, boolean exposeConnection) is annotated with @Nullable while it is not a method that is exposed on the interface.