Extending AbstractThrowableProblem not working as expected in Kotlin

When extending AbstractThrowableProblem in Java it works as expected. Extending the class in Kotlin leads to a compile error:

Class 'MyProblem' is not abstract and does not implement abstract base class member public abstract fun getCause(): Exceptional! defined in org.zalando.problem.AbstractThrowableProblem

Description

Working Java Problem:

public class MyProblemJava extends AbstractThrowableProblem {

    public MyProblemJava(String message) {
        super(URI.create("https://www.google.de"), "My Problem", Status.BAD_REQUEST, message);
    }
}

The same problem converted to Kotlin

import org.zalando.problem.AbstractThrowableProblem
import org.zalando.problem.Status.BAD_REQUEST
import java.net.URI

class MyProblem(message: String?) : AbstractThrowableProblem(TYPE, "My Problem", BAD_REQUEST, message) {

    companion object {
        val TYPE = URI.create("https://www.google.de/workflow-problem")
    }
}

Expected Behavior

MyProblem should not have to override getCause() as the Java class does not have to do, either.

Actual Behavior

Compilation issue.

Your Environment

• Version used: 0.22.0
• also found here: https://stackoverflow.com/questions/53761722/java-to-kotlin-conversion-extending-abstract-class

[whiskeysierra]

as AbstractThrowableProblem doesn’t override the getCause method

It inherits it from ThrowableProblem. There is no reason to implement it again:

https://github.com/zalando/problem/blob/21e28bcfbdb3984d0f26a2a44b729b88ddb5f709/problem/src/main/java/org/zalando/problem/ThrowableProblem.java#L38-L42

I have no idea if this is a Kotlin issue

Since it works in Java I’m inclined to say yes.

[jehrenzweig-leagueapps]

Looks like the issue that @unlimitedsola reported, wrt the IR backend (https://youtrack.jetbrains.com/issue/KT-45853), is fixed.

This comment was posted with regards to the need to redundantly override getCause() with the same implementation as the superclass (i.e. super.getCause()):

Hi , you are right. This is caused by "Inconsistent override tree when Kotlin property accessor is 
covariantly overridden by a Java method" (https://youtrack.jetbrains.com/issue/KT-46042), 
which, unfortunately, we can't fix right away without deprecation cycle.