To work with a Java API, I need to create a method...

# announcements

[Ellen Spertus]

To work with a Java API, I need to create a method whose return type is Void and has the following behavior:

override fun getResult(): Void {
        if (!success) throw RuntimeException()
    }

This doesn't compile, because a function with a block body requires a return statement.

[Ellen Spertus]

How can I fix this code?

[Ruckus]

You probably actually want to return Void? (remember Java doesn't have null safety).

override fun getResult(): Void? {
    if (success) return null
    else throw RuntimeException()
}

[James]

override fun getResult(): Unit {
        if (!success) throw RuntimeException()
    }

[James]

do you need to return Void explicitly?

[karelpeeters]

Doesn't Java also require a return statement?

[James]

that is kotlin

[Ellen Spertus]

I believe so, because I'm extending Task<Void>, which requires implementing getResult(): Void.

[Ellen Spertus]

This compiles, but it's not exactly what I want:

override fun getResult(): Void {
        throw RuntimeException()
    }

[Ruckus]

@Ellen Spertus Did my code not do what you expected?

[Ellen Spertus]

Sorry, @Ruckus, your code scrolled off my screen, and I missed it at first.

[Ruckus]

Basically, you can't actually return a Void value, just like you can't return a Nothing value in Kotlin (there is no instance of Void). In order to get this to work, you either need to diverge (not return like your always fail example) or change your return type (you can use Void? to fit better into the Java world, or if it makes more sense you can change to extend Task<Unit> and use @James's code.

[Casey Brooks]

In Java, Void has a private constructor, so it is impossible to actually get an instance of Void. Any method contract that requires you to return Void is implicitly requesting you return null instead. I think having your Kotlin method have a return type of Void? and returning null on the success branch is the way to go.

[Ellen Spertus]

Yes, @Ruckus, your solution works. I didn't think I'd be able to change the return type. Thank you very much!

[Ruckus]

Yeah, Kotlin has to make some assumptions when overriding Java, so if there's no annotations it chooses the "safest" by default (arguments are nullable and return types aren't), but they're actually platform types so you can choose your nullability as you see fit.

[Stephan Schroeder]

I’m with James, I assume Kotlin’s Unit to be mapped to Java’s void. So

override fun getResult(): Unit {
    if (!success) throw RuntimeException()
}

should work and is more idiomatic than Void?.
This playground code overrides Java’s Object’s finalize method which returns void in Java by using Unit and it works fine:

class KotlinObject() : java.lang.Object() {
    override fun finalize(): Unit {}
}

https://pl.kotl.in/n_umKF6c8

[karelpeeters]

But none of that works if Java code is forcing you to implement Task<Void>.

[Stephan Schroeder]

It’s interesting that the interop doesn’t automatically translate Task<Unit> but it does Task<Void?>, because technically Void? is as far from Void as is Unit. (What about ’Nothing?which is the same set as 'Void???)
I guess that the instance of Task<Void?> is passed back to Java code? Because otherwise using Task<Unit> is probably the answer. Something similar happens when I want to use the ExecutorService, which only handles `Callable`s and not `Runable`s. In that case Callable<Unit> is the way to go.

[Ruckus]

technically Void? is as far from Void as is Unit

What? How on Earth did you come to that conclusion? Void has nothing to do with Unit.

[Casey Brooks]

The difference is that Task<Unit> must return something, namely Unit.INSTANCE. Task<Void> does not make sense, since you cannot get a non-null instance of Void to return, and thus Task<Void?> must return null

[Casey Brooks]

Unit is analogous to void in the sense that it is the default return type, but it is not the same thing as void. void has no instance, unit has an instance and is non-null, and has a different meaning from void in Kotlin’s null-safe world