I've got Java Code that looks like this (Spring's ...

# getting-started

[Bernhard]

I've got Java Code that looks like this (Spring's ResponseEntity<T>)

class Container<T> {
    @Nullable
    private T value;

    public Container(@Nullable T value) {
        this.value = value;
    }

    @Nullable
    public T getValue() {
        return value;
    }
}

Obviously, creating a Container<String> in Kotlin will still force the container.value return type to be nullable; is there a nice way around that? I've currently resorted to:

val <T> ResponseEntity<T>.nonNullBody: T
    get() = body!!

[Sam]

Maybe you could subclass it? Bit messy, but it should work.

class MyContainer<T>(private val value: T): Container<T>(value) {
  override fun getValue(): T = value
}

[Bernhard]

yeah, problem is that I don't have access to where it's created

[Bernhard]

container is being returned from Spring Proxies built out of Interfaces

[Sam]

I don't think you can fix it then. The problem is basically that the nullability annotations in the Spring source code are wrong (or at least, imprecise). IMO the generic parameter should be annotated nullable and the other methods should have no annotations.

[Bernhard]

would basically need to wrap all proxy methods

[Bernhard]

I see, thank you

[Bernhard]

looking at org.springframework.lang.Nullable or the jakarta equivalent, none can be applied to type parameters

[Sam]

I've not used nullability annotations much but I'm wondering if they're really needed at all in that scenario. I'm sure most type systems that understand nullability would get it right without the annotations. Adding the annotations serves no purpose but to mistakenly imply that getValue can return null even when T was originally non-nullable 😢

[Bernhard]

no, not how that works

[Bernhard]

if you don't annotate it, it will return a platform type

[Bernhard]

as in: Container<String> will return String! instead of String for the getter

[Bernhard]

not even making the property final will do that

[Bernhard]

ok, found the solution

[Bernhard]

jetbrains annotations were pulled in in version 13.x.x, you can add those annotations in newer versions to produce that result

[Bernhard]

unfortunately does not fix Spring's usage

[asdf asdf]

What’s the problem with it being a platform type? You can use it like a non-nullable type

[Bernhard]

@asdf asdf I think Spring went out of it's way to add nullability information to give you a better Kotlin experience

[Bernhard]

platform types are basically "can explode" types

[Bernhard]

so you aren't sure if they're null or not