| FazBrowse GitHub Viewer | Trending | | Home |
| Tools: [Download Repo ZIP] [Original HTTPS Page] |
The @NullMarked annotation on DataFetchingEnvironment makes type parameters implicitly non-null, but java-dataloader's DataLoader declares V extends @nullable Object to allow nullable values. This mismatch prevents Kotlin consumers from expressing nullable value types without unsafe casts when returning CompletableFuture from data fetchers. Add explicit V extends @nullable Object bound to match DataLoader's type signature, enabling proper nullability propagation to Kotlin.
There was a problem hiding this comment.
Thanks for this.
Moving to JSpecify is an interesting exercise because while it "allows for more precise nullability specifications" its only the Kotlin compiler that truly enforces it.
So this mismatch for example survives a Java compile but not a Kotlin one.
I wonder if we are missing some Java setting that would catch this earlier
Sorry, something went wrong.
| Back | FazBrowse Home | New Git URL |
The @NullMarked annotation on DataFetchingEnvironment makes type parameters implicitly non-null, but java-dataloader's DataLoader declares V extends @nullable Object to allow nullable values.
This mismatch prevents Kotlin consumers from expressing nullable value types without unsafe casts when returning CompletableFuture from data fetchers.
Add explicit V extends @nullable Object bound to match DataLoader's type signature, enabling proper nullability propagation to Kotlin.
#4179