ResponseEntity body nullability issue with Kotlin

[alfonsoristorato]

Hi there, since Spring 4 and the introduction of JSpecify I am no longer able to declare some nullable types in ResponseEntity.

For example, such an endpoint:

@RestController
class HelloController {
    @GetMapping("/hello")
    fun hello(): ResponseEntity<String?> {
        val maybeHello :String? = "hey"
        return ResponseEntity.ok(maybeHello)
    }
}

would return a ResponseEntity with body String, or a ResponseEntity with null body (according to whatever logic determines whether the body is null or not).
Leaving alone as to whether or not this is a recommended Rest endpoint, I would expect this to compile properly, especially due to ResponseEntity contract, which is as follows (current version 7.0.2):

	public static <T> ResponseEntity<T> ok(@Nullable T body) {
		return ok().body(body);
	}

However, although the IDE does not recognise this as an error (cause I assume it should not be, given @Nullable), when I compile I get the following error:

exception: src/main/kotlin/.../Application.kt:19:33: error: type argument is not within its bounds: must be subtype of 'Any'.
exception:     fun hello(): ResponseEntity<String?> {
exception:                                 ^^^^^^^
exception: src/main/kotlin/.../Application.kt:21:16: error: return type mismatch: expected 'ResponseEntity<String?>', actual 'ResponseEntity<String>'.
exception:         return ResponseEntity.ok(maybeHello)
exception:                ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

I understand that I can completely omit ResponseEntity and just return the nullable body, but I am confused as to why Jsepcify is not recognising this kotlin nullability.
I have read that there are still teething issues when it comes to Jspecify and generics, but I wonder if this would fall under this category, and if so what is your recommendation for the short term.

[ngocnhan-tran1996]

You can try this

@RestController
class HelloController {
    @GetMapping("/hello")
    fun hello(): ResponseEntity<String> {
        val maybeHello :String? = null
        return ResponseEntity.ok(maybeHello)
    }
}

[alfonsoristorato]

Yeah, this is what I am doing at the moment, and it compiles property and handles the nullability correctly when the body is indeed null.
But that is very much counter intuitive to me, plus for whatever openApi reader it will be quite unclear that the body can indeed be null

[sbrannen]

I would expect this to compile properly, especially due to ResponseEntity contract, which is as follows (current version 7.0.2):

public static <T> ResponseEntity<T> ok(@Nullable T body) {
	return ok().body(body);
}

Unless I'm mistaken, that declaration specifies that you can supply a null body to the method, but it does not specify that the T in the returned ResponseEntity is allowed to be null.

Perhaps methods like that ok(...) method should rather be declared as follows.

public static <T extends @Nullable Object> ResponseEntity<T> ok(T body) {
	return ok().body(body);
}

@sdeleuze, thoughts?

[alfonsoristorato]

I would expect this to compile properly, especially due to ResponseEntity contract, which is as follows (current version 7.0.2):
public static ResponseEntity ok(@nullable T body) {
return ok().body(body);
}

Unless I'm mistaken, that declaration specifies that you can supply a null body to the method, but it does not specify that the T in the returned ResponseEntity is allowed to be null.

Perhaps methods like that ok(...) method should rather be declared as follows.

public static <T extends @nullable Object> ResponseEntity ok(T body) {
return ok().body(body);
}
@sdeleuze, thoughts?

That could potentially work, what is unclear to me is what makes the compiler think this is non-nullable.
Before introducing Jspecify any method with a generic T would infer that T to be indeed nullable, and obviously Kotlin would interpret it the same, as generics are handled the same way, whereas now Kotlin is interpreting this as

.... <T : Any> ....

Thanks for looking into it btw :) and I would be happy to help if this requires a big refactor (as it's not only the ok method that is affected).

[sbrannen]

That could potentially work, what is unclear to me is what makes the compiler think this is non-nullable.

The reason is that ResponseEntity is part of the org.springframework.http package, and that package is "null marked".

spring-framework/spring-web/src/main/java/org/springframework/http/package-info.java

Lines 5 to 6 in 516bf1c

	@NullMarked
	package org.springframework.http;