java - Should I remove the nullability of overriden methods that are not annotated with nullable in an inherited class

android kotlin (4)

They are not specified as nullable annotation in the Java code.

If that's true note that you risk throwing a NullPointerException if not specified as nullable annotation in the Java code and assign a null value. so remove the nullability from the overridden method if not specified as nullable annotation in the Java code.

For more detail read this also

Android 3.5.1

I was using the WebView and I noticed that when I override some of the methods all the parameters are nullable types:

webview.webViewClient = object : WebViewClient() {
    override fun shouldOverrideUrlLoading(view: WebView?, request: WebResourceRequest?): Boolean {
         return super.shouldOverrideUrlLoading(view, request)

Which means I have to use the safe call operator to use them. However, when I looked at the WebViewClient class that I have overridden the method from they are not specified as nullable annotation in the Java code.

public boolean shouldOverrideUrlLoading(WebView view, WebResourceRequest request) {
    return shouldOverrideUrlLoading(view, request.getUrl().toString());

So I am left thinking do I remove the nullability from the overridden method or keep them?

If a virtual method in Java doesn't specify nullability of its parameters somehow, for example with the @Nullable / @NotNull annotations, you are free to choose the nullability either way when overriding that method in Kotlin.

But how should you choose?

  • First, you can consult the method documentation and check the method contract. Does it specify that the method can be called with nulls, and what would these nulls mean when passed to the method?

    In this particular case, WebViewClient.shouldOverrideUrlLoading method doc page doesn't say anything about nulls, so it can be taken as an evidence that its parameters are supposed to be non-nullable .

  • Second, if you are still unsure about the nullability after consulting the docs, you can consider what would you do with the null parameter value, if you receive one. If the only reasonable thing in this situation is to throw an exception, you can delegate that check to the parameter checking code generated by Kotlin—by declaring parameters as non-nullable.

On the language-level, this can be generalized:

For proper Java interoperability, the Kotlin code should reflect the annotations of the Java code.

The linter only complains about lacking annotations in the other direction, for Kotlin interoperability.

See this recent article on How to write Java friendly Kotlin code?

The source of this issue comes from Interoperability between Java and Kotlin . There are some basic language level differences between Java and Kotlin which causes interoperability issues. Android Studio provides some Lint checks to warn them, such as Unknown Nullness . ( reference )

By taking a look at details of Unknown nullness Lint check from , we see that:

To improve referencing code from Kotlin , consider adding explicit nullness information here with either @NonNull or @Nullable .

and on :

If you use Kotlin to reference an unannotated name member that is defined in a Java class ( e.g. a String ), the compiler doesn't know whether the String maps to a String or a String? in Kotlin . This ambiguity is represented via a platform type , String! .

and on :

Any reference in Java may be null , which makes Kotlin 's requirements of strict null-safety impractical for objects coming from Java . Types of Java declarations are treated specially in Kotlin and called platform types .

Therefore, when we override a Java method that its arguments are not annotated with nullity annotations, the IDE adds nullable sign ( ? ) for arguments in Kotlin class. It leads to avoid throwing NullPointerException when the method is called in Java by passing a null value for one of the arguments.

webview.webViewClient = object : WebViewClient() {
    override fun shouldOverrideUrlLoading(
        view: WebView, // <- potential to throw NPE before executing the function block!
        request: WebResourceRequest // <- as well!
    ): Boolean {
        return super.shouldOverrideUrlLoading(view, request)

In a nutshell, we SHOULD NOT remove ? sign from function arguments, when the overridden method is defined in a Java class.