@Nullable Annotations for Option<T>

[ShayBox]

I'm using this with Kotlin because it supports FFM, but when I use Option<T> it doesn't generate @Nullable annotations, so Kotlin assumes it's not nullable. I think this would also generally be a good idea because LSPs can still warn Java users with the same annotations.

[skeet70]

In my experience with Java, you always defensively programmed because any Object could be null. @Nullable is a suggestion, not a compiled promise. Do you know the current state there? As far as I can tell, there's no @Nullable in the std library for Java. There have been different attempts every few years since like 2010 to provide them. It looks like Kotlin knows about and uses the JetBrain, Jspecify, or Eclipse ones. What happens if we make a choice (like jspecify). Does that interact badly if a consumer is using Eclipse annotations?

[ShayBox]

Unfortunately null-ability is still not a first class citizen of Java, and it probably never will be, but I would still prefer using annotations over nothing if I was writing Java.

You can configure your language server / linter? to treat everything not annotated as null-able, which is technically correct, and would either give you in-editor suggestions/warnings or even build time errors at the strictest, but most people don't go that strict.

As far as I know JSpecify has become the defacto, while Eclipse and JetBrains annotations still exist, and they're all interchangeable, there's talks of deprecating Eclipse and JetBrains annotations in favor of JSpecify, but who knows if that would ever happen.

https://www.jetbrains.com/help/idea/annotating-source-code.html#default_nullability_annotations

Though with it still being a third party library, it might have to be behind a feature flag because not everyone will have it available.

[skeet70]

The core change for this (switching fully_qualified_type_label in mod.rs for Option to check for the config value and add the annotation) was pretty basic. I put up a branch at 61-nullable-annotations that took that and AI generated some of the surrounding mechanical bits and tests.

You can give it a shot and see if it works for you, I don't have a project to integration test the instruction with right now.

[ShayBox]

I believe I installed it and enabled it, but it doesn't seem to be working.
cargo install uniffi-bindgen-java --git https://github.com/IronCoreLabs/uniffi-bindgen-java#branch=61-nullable-annotations

[bindings.java]
package_name = "tools.shay"
cdylib_name = "native"
nullness_annotations = true

[bindings.java.custom_types.Uuid]
type_name = "UUID"
imports = ["java.util.UUID"]
into_custom = "UUID.fromString({})"
from_custom = "{}.toString()"

#[derive(Debug, Archive, Deserialize, Serialize, Enum)]
pub enum ServerboundMessage {
    Login {
        id:       Option<Uuid>,
        username: String,
        test:     Option<String>,
    },
}

package tools.shay;

public sealed interface ServerboundMessage {
  
  record Login(
    tools.shay.Uuid id, 
    java.lang.String username, 
    java.lang.String test) implements ServerboundMessage {
    
    
    

  }
  

  
}

[skeet70]

Try cargo install uniffi-bindgen-java --git https://github.com/IronCoreLabs/uniffi-bindgen-java --branch 61-nullable-annotations instead of #branch=name, per the docs

[ShayBox]

Ah that was it, thank you.

It seems the syntax is different, but I'm not sure I've ever seen this before.

It's generating this: @org.jspecify.annotations.Nullable java.lang.String test
But it's supposed to be: tools.shay.@org.jspecify.annotations.Nullable Uuid id
Or java.lang.@org.jspecify.annotations.Nullable String test

I didn't know that was the syntax with import path, it seems strange but that compiles and works.
At least in this case as parameters to a record.

package tools.shay;

public sealed interface ServerboundMessage {
  
  record Login(
    @org.jspecify.annotations.Nullable tools.shay.Uuid id, 
    java.lang.String username, 
    @org.jspecify.annotations.Nullable java.lang.String test) implements ServerboundMessage {
    
    
    

  }
  

  
}

package tools.shay;

public sealed interface ServerboundMessage {

    record Login(
            tools.shay.@org.jspecify.annotations.Nullable Uuid id,
            java.lang.String username,
            java.lang.@org.jspecify.annotations.Nullable String test) implements ServerboundMessage {


    }


}

[skeet70]

Weird, I wasn't aware of the declaration vs type-use annotation distinction on that. I'll update it to generate the JLS 9.7.4 version that worked for you.

For example, assume an annotation type TA which is meta-annotated with just @ Target(ElementType.TYPE_USE). The terms @ TA java.lang.Object and java.@ TA lang.Object are illegal because the simple name to which @ TA is closest is classified as a package name. On the other hand, java.lang.@ TA Object is legal.

[skeet70]

@ShayBox that fix is pushed.

[ShayBox]

It seems to be working for me, I'll let you know if I have any more problems. Thank you