DDevelopment & Design

Kotlin Type-Inference Puzzler

Kotlin takes Type-Inference to the next level (at least in comparison to Java) which is great, but there’re scenarios, in which it can backfire on us.

The Riddle

fun foo(int: Int?) = {
    println(int)
}

fun main(args: Array<String>) {
    listOf(42).forEach { foo(it) }
}

And the question is: what does the puzzler() method print and why it’s not 42? Assume that the main() method gets executed.

The answer can be found at the very end of the article.

Explanation

In Kotlin, we’ve got not only a local variable type inference (which is also coming to Java) but also the return value type inference when writing single-expression methods.

Which means that if we write a method:

fun foo() : String  {
    return "42"
}

We can rewrite it using the single-expression method syntax and ignore the explicit type declaration and the return keyword:

fun foo() = "42"

So, if we have a method:

fun foo(int: Int?) : Unit {
    println(int)
    return Unit
}

we could get rid of the return type declaration, as well as the explicit return statement by leveraging single-expression method syntax, right? but we already know that the following doesn’t work:

fun foo(int: Int?) = {
    println(int)
}

The devil’s in the details but everything becomes crystal clear if we specify the return type explicitly:

fun foo(int: Int?) : () -> Unit = {
    println(int)
}

If we look closely, it can be seen that we mixed two approaches here and actually defined a method that doesn’t return Unit but a () -> Unit itself – which is simply an action that doesn’t accept any parameters and doesn’t return anything – which is semantically equivalent to returning a java.lang.Runnable instance.

This is because Kotlin utilizes curly braces not only for defining classes/methods but also for defining Lambda Expressions and { println(42) } is a valid Lambda Expression declaration:

val foo: () -> Unit = { println(42) }

So, our original example is simply a Higher-Order Function accepting an Int parameter and returning a function that prints it – when we return it in the forEach() the return value just gets ignored.

So, if we want to fix our example, we have two ways to go.

Explicitly call invoke() on the returned function:

listOf(42)
  .forEach { foo(it).invoke() }

or simply define the method properly by removing the “=” sign:

fun foo(int: Int?) {
    println(int)
}

or by leveraging the single-expression method syntax:

fun foo(int: Int?) = println(int)

That’s why I encourage my fellow team members to declare return types explicitly.

Code snippets can be found on GitHub.

Answer

The method prints nothing.

— Previous article

Karaf configuration as Groovy file

Next article —

MapStruct mapper injection in OSGi Blueprint

You May Also Like
DDevelopment & Design

Grails render as JSON catch

One of a reasons your controller doesn't render a proper response in JSON format might be wrong package name that you use. It is easy to overlook. Import are on top of a file, you look at your code and everything seems to be fine. Except response is still not in JSON format.

Consider this simple controller:

class RestJsonCatchController {
def grailsJson() {
render([first: 'foo', second: 5] as grails.converters.JSON)
    }

def netSfJson() {
render([first: 'foo', second: 5] as net.sf.json.JSON)
    }
}

And now, with finger crossed... We have a winner!

$ curl localhost:8080/example/restJsonCatch/grailsJson
{"first":"foo","second":5}
$ curl localhost:8080/example/restJsonCatch/netSfJson
{first=foo, second=5}

As you can see only grails.converters.JSON converts your response to JSON format. There is no such converter for net.sf.json.JSON, so Grails has no converter to apply and it renders Map normally.

Conclusion: always carefully look at your imports if you're working with JSON in Grails!

Edit: Burt suggested that this is a bug. I've submitted JIRA issue here: GRAILS-9622 render as class that is not a codec should throw exception