[java interop] How can I overcome java `@Nullable`...

# getting-started

[David Kubecka]

[java interop] How can I overcome java @Nullable which is overly pessimistic?

For example, I want to create a shortcut for transactions execution:

fun <T> PlatformTransactionManager.execute(block: () -> T): T =
    TransactionTemplate(this).execute { _ -> block() }

This doesn't compile because execute is marked as @Nullable, therefore the return type must be T?. Instead would like it to be T, that is whatever block returns (which might also be null).

[Rob Elliot]

Can you just throw an exception?

fun <T> PlatformTransactionManager.execute(block: () -> T): T =
    TransactionTemplate(this).execute { _ -> block() } ?: throw IllegalStateException("Expected it to be impossible for execute to return null")

[David Kubecka]

As I said, the block can return null. I highlighted that part of my question 🙂

[Rob Elliot]

Oh I see, sorry

[Riccardo Lippolis]

fun <T> PlatformTransactionManager.execute(block: () -> T): T =
        TransactionTemplate(this).execute { _ -> block() } as T

this appears to be working, and it removes the warning

[David Kubecka]

Yes, it works, but it generates a warning, not removes one 😞

[Riccardo Lippolis]

oh weird, my IDE did not give any warning there...

[Riccardo Lippolis]

image.png

[ephemient]

if you don't want to see the warning on as T,

@Suppress("UNCHECKED_CAST")

[Riccardo Lippolis]

hmm, weird that I don't need that suppression (did not disable that warning in IntelliJ)

[David Kubecka]

Weird indeed. Does it compile without warnings? (btw I also use IDEA)

[kqr]

i feel stupid right now, but if it can return null how can it be T ?

[David Kubecka]

Plain <T> doesn't say anything about its nullability (in contrast to e.g. <T : Any> )

[kqr]

ah, thx

[David Kubecka]

I guess the confusion might be about the difference between T and T?. Well, T in this case means the exact return type of the block (preserving nullability), while T? might not preserve the nullability, i.e. even if block returned non-null then TransactionTemplate#execute might still return null.

I guess that's a principal deficiency of those java annotations.

[Riccardo Lippolis]

Weird indeed. Does it compile without warnings? (btw I also use IDEA)

yes, no compiler warnings as well... I use Kotlin 1.8.10, btw

[deive]

If you know that what you run in execute never returns a null, then why not use a !! ?

fun <T> PlatformTransactionManager.execute(block: () -> T): T =
    TransactionTemplate(this).execute { _ -> block() }!!

[Rob Elliot]

It can return null if the block returns null. It should have the same type as the block, which may or may not be nullable

[deive]

As in, if TransactionTemplate.execute returns T? but you are always running block: () -> T then TransactionTemplate(this).execute { _ -> block() }!! should be OK?

[Rob Elliot]

i.e.

val x: String = tm.execute { "not null" }
val y: String? = tm.execute { if (Random.nextInt(2) == 1) "not null" else null }

[ephemient]

basically a mismatch between Java (where <T> is neither nullable nor non-nullable) and Kotlin (where there is such a distinction)

[ephemient]

Java @Nullable <T> T foo() becomes Kotlin fun <T> foo(): T?, Java @NonNull <T> T foo() becomes Kotlin fun <T> foo(): T & Any, and <T> T foo() can't be written directly in Kotlin due to platform nullability. none of them result in fun <T> foo(): T

[deive]

I missed part of the original question as well "that is whatever block returns (which might also be null)." - this means that block will have to return T? so what I said was moot!

[Rob Elliot]

No, the block returns T. Whether or not `T`'s concrete type is nullable depends on how you define the block.

[Rob Elliot]

val notNullBlock: () -> String = { "not null" }
val x: String = tm.execute(notNullBlock)

val nullableBlock: () -> String? = { if (Random.nextInt(2) == 1) "not null" else null }
val y: String? = tm.execute(nullableBlock)

[deive]

yeah, sorry, would you change PlatformTransactionManager.execute to be fun <T : Any> for a non-nullable version?

[Rob Elliot]

Yes

[deive]

Thanks, sorry for my confusion there!

[Rob Elliot]

I missed the important bit too right at the start of the conversation