With kotlin and smallyre sometimes I need to declare the type again.
Additional details
Examples:
.transformToMulti { fetch(it.bananas).onItem().disjoint<Banana>() }
Without <Banana> it doesn't know that I fetch the Bananas.
.call { it -> if (it.type?.entityType == Apple) serviceApple.updateBy(it) else createUniFrom().nullItem<Apple>() }
Without <Apple> it doesn't know that it should return a nullItem with this type.
But shouldn't it know it already, because I return an Uni in the true case?
PS: nullItem<Void> and nullItem<Unit> are working too, which confuses me more.
There is .voidItem(), but that I would otherwise need to declare the type confuses me.
Maybe the java code of smallrye confuses kotlin?
Maybe we need kotlin classes as a layer in smallrye which optimize the kotlin compatibility?
As far as I know the Quarkus Framework uses this approach.
PS: I like the word confusing
With kotlin and smallyre sometimes I need to declare the type again.
Additional details
Examples:
.transformToMulti { fetch(it.bananas).onItem().disjoint<Banana>() }Without
<Banana>it doesn't know that I fetch the Bananas..call { it -> if (it.type?.entityType == Apple) serviceApple.updateBy(it) else createUniFrom().nullItem<Apple>() }Without
<Apple>it doesn't know that it should return a nullItem with this type.But shouldn't it know it already, because I return an Uni in the true case?
PS:
nullItem<Void>andnullItem<Unit>are working too, which confuses me more.There is
.voidItem(), but that I would otherwise need to declare the type confuses me.Maybe the java code of smallrye confuses kotlin?
Maybe we need kotlin classes as a layer in smallrye which optimize the kotlin compatibility?
As far as I know the Quarkus Framework uses this approach.
PS: I like the word
confusing