auth0-java icon indicating copy to clipboard operation
auth0-java copied to clipboard

Add Jetbrains nullability annotations to POJO classes

Open tbcrawford opened this issue 8 months ago • 2 comments

Checklist

  • [x] I have looked into the Readme and Examples, and have not found a suitable solution or answer.
  • [x] I have looked into the API documentation and have not found a suitable solution or answer.
  • [x] I have searched the issues and have not found a suitable solution or answer.
  • [x] I have searched the Auth0 Community forums and have not found a suitable solution or answer.
  • [x] I agree to the terms within the Auth0 Code of Conduct.

Describe the problem you'd like to have solved

When interfacing with the POJO classes from Kotlin we end up with platform types.

In short, platform types are a type that comes from another language (Java) that has unknown nullability. This can be problematic for Kotlin because some field that we assume to not be null can be null and lead to NullPointerExceptions. Adding nullable annotations should be useful for any JVM language interfacing with this library.

Describe the ideal solution

Add @Nullable and @NotNull annotations to all POJO classes and types publicly exposed.

Alternatives and current workarounds

The more dangerous alternative is to assume the nullability of a type and effectively cast it to that type in Kotlin, but we end up with typed fields all over the place which become unnecessary.

Something like:

val user = User() // assume this is `com.auth0.json.mgmt.users.User` that has values
val name: String = user.name // This will call user.getName() in Java and effectively cast it as not nullable, which is incorrect

Additional context

No response

tbcrawford avatar May 17 '25 23:05 tbcrawford

Hi @tbcrawford

Thanks for pointing this out.

You're right — platform types in Kotlin can lead to unsafe assumptions when nullability isn’t defined in Java. Adding @Nullable and @NotNull annotations to our public APIs is the ideal fix for better Kotlin interoperability.

While this isn’t currently on our immediate roadmap, we really appreciate any contributions in this area and are happy to review them. In the meantime, using safe calls or null checks in Kotlin is the best workaround.

Thank you

tanya732 avatar Jun 04 '25 05:06 tanya732

Looking at the API spec, I don't see the nullability described there (I got bit by this today with organization metadata)

jasonab avatar Oct 01 '25 02:10 jasonab