Kotlin - ifNotNull offers a nullable receiver

[MartinX3]

Context

A .transform returns either a null or a value.
Using .onItem().ifNotNull().call { entity -> gives a nullable entity and kotlin complains.

Description

ifNotNull offers a nullable receiver. Kotlin complains and wants a null-check.

Additional details

Using Java 18.0.1, Kotlin 1.6.10 and Quarkus 2.8.1.Final

[heubeck]

Would like to explore, were and which @NotNull and @Nullable hints could make sense in general.
With Kotlin, the compiler complains, but also IDE support may improve with those.

Options: https://kotlinlang.org/docs/java-interop.html#nullability-annotations

Guess jsr305 will make the race: https://kotlinlang.org/docs/java-interop.html#jsr-305-support

With an own nicknamed annotation type, for best flexibility - WDYT?

[MartinX3]

Thank you for the exploration.

I would tend to @Nullable and @NotNull from the org.jetbrains.annotations package, since Kotlin is from JetBrains.
The jsr305 is dormant since 2012 so I get a bad feeling about using it.

Also jsr305 makes license issues with oracle and software issues.
See google/guava#2960

[heubeck]

Thank you for the exploration.

I would tend to @Nullable and @NotNull from the org.jetbrains.annotations package, since Kotlin is from JetBrains. The jsr305 is dormant since 2012 so I get a bad feeling about using it.

Also jsr305 makes license issues with oracle and software issues. See google/guava#2960

Thank you for your thoughts. I would like to provide the type-safety, but also avoid shipping an additional dependency for that purpose.

What about some own Mutiny annotations, and the associated compiler options in the guide?

[MartinX3]

That sounds nice.
Is it possible to add compiler options in the Mutiny Framework?
It would be bad if I would need to add compiler options myself. If I google about it I only find the need to add gradle and maven arguments in my own gradle/maven file.

Here are additional resources:

• https://github.com/JetBrains/kotlin/blob/master/core/compiler.common.jvm/src/org/jetbrains/kotlin/load/java/JvmAnnotationNames.kt
• https://youtrack.jetbrains.com/issue/KT-48623

[heubeck]

Ok...
the compiler options I thought about are only related to the jsr-305 annotations, own ones are not possible.

What's described in your mentioned ticket

https://youtrack.jetbrains.com/issue/KT-48623
seems to affect my trials: IDE (Intellij) shows nullable type hints (String?) but compiler does not complain on non-null safe access like value.length.

It's not consistent right now, so hopefully becomes better with Kotlin 1.7.
Also it seems like under some circumstances, nullable types are correctly inferred when Mutiny types are declared in Kotlin sources.

So for now, it's not possible to include type safety without shipping additional libraries, and even with them, it's not consistent between Intellij and the Kotlin compiler.

We could try to add @NotNull and @Nullable to smallrye-commons and propose to add those to

https://github.com/JetBrains/kotlin/blob/master/core/compiler.common.jvm/src/org/jetbrains/kotlin/load/java/JvmAnnotationNames.kt
(what would be really cool in my opinion).

@jponge, I would like to hear your opinion on this - and maybe if there's further added value on hinting nullable in Mutiny (or if there's already something present in other smallrye projects, that can be adopted.

[MartinX3]

Also I see that Uni.combine().all().unis(a,b,c).combinedWith { a,b,c -> fun()} always claims, that a,b,c are not nullable, but I don't use Unis with notNull().

Also the Uni.combine().all().unis(a,b,c).combinedWith { a,b,c -> fun()} throws the error Not enough information to infer type variable O and Cannot infer a type for this parameter. Please specify it explicitly if I use more than 9 Unis.
And even if I specify the types of the parameter, which fixes Cannot infer a type for this parameter. Please specify it explicitly I still get the error Not enough information to infer type variable O at combine().all().unis()

[heubeck]

Issue to be postponed for... some while.
See: #1052