Hi :wave:, maybe a silly question related to Java/Kotlin interop, I face something that worries me :...

# announcements

[Olivier Patry]

Hi 👋, maybe a silly question related to Java/Kotlin interop, I face something that worries me 😱

In Java, a legacy class exposes

public void setFoo(@NonNull Bar bar)
{
  // ...
}

In Kotlin side

myObject.foo = null // OK
myObject.setFoo(null) // KO

The property access compiles 😱
The function call doesn't compile 👍

Is it expected?
Can I avoid exposing setFoo as a Kotlin property at will?
It seems fragile to allow such property access, no?

[rnett]

Seems like a bug. Is the getter also @NonNull? https://youtrack.jetbrains.com/issue/KT-33393 is close

[Olivier Patry]

Indeed, the getter isn't @NonNul but @Nullable, so I guess it brings such conflict…
My use case might be a bit weird, I have get/set and clear for this API.
In fact, what I'd like here is to disabled property feature of Java/Kotlin interop for this specific APIs.
Maybe my use case can't be achieved?

[Olivier Patry]

Oh, I double checked and in fact, getFoo isn't annotated at all 😱

[Olivier Patry]

public class Foo {
//    @Nullable
    public String getFoo() { return ""; }

    public void setFoo(@NonNull String bar) { }

    public void clearFoo() { }
}

[Olivier Patry]

If getFoo isn't @Nullable then

fun x() {
    val foo = Foo()
    foo.setFoo(null)
    foo.foo = ""
    foo.foo = null
    foo.clearFoo()
}

[Olivier Patry]

both foo.foo assignments will compile, if it's @Nullable, then both assignments won't compile

Val cannot be reassigned

[Olivier Patry]

At the light of your hint, everything becomes obvious now. I wasn't looking at the whole problem, only focusing on setFoo