Repository navigation
DataFetcherResult.newResult<T>() type parameter missing @Nullable bound for Kotlin JSpecify interop #4364
Description
Describe the bug
DataFetcherResult<T extends @Nullable Object> and Builder<T extends @Nullable Object> correctly allow nullable T. However, the no-arg factory method still declares <T> without the @Nullable bound:
public static <T> Builder<T> newResult() {
return new Builder<>();
}Under @NullMarked, Kotlin 2.1+ infers T : Any, making DataFetcherResult.newResult<MyType?>() a compile error.
This is the same class of issue as #4179 (getDataLoader type bounds, fixed in #4180), but for DataFetcherResult.
To Reproduce
// graphql-java 25.0, Kotlin 2.3+
// Compile error: Type argument is not within its bounds: must be subtype of 'Any'
val result = DataFetcherResult.newResult<String?>()
.data(null)
.build()Expected behavior
The above should compile. Fix:
- public static <T> Builder<T> newResult()
+ public static <T extends @Nullable Object> Builder<T> newResult()Note: A fix already exists on branch claude/kotlin-jspecify-e2e-test-rdaLf (commit f8f06a25, Mar 8 2026) but has no associated PR.
Versions: graphql-java 25.0, Kotlin 2.3.20
Activity
Fix DataFetcherResult.newResult() type parameter bounds for Kotlin JS…
Add ArchUnit check for @nullable type parameter bounds and fix DataFe…
Fix #4364 and #4200: nullable type bound and empty union extension su…
github-actions commentedon Jun 2, 2026
Hello, this issue has been inactive for 60 days, so we're marking it as stale. If you would like to continue this discussion, please comment within the next 30 days or we'll close the issue.
Syer10 commentedon Jun 2, 2026
Active
bbakerman commentedon Jun 6, 2026
This is fixed. I am going to close it
mrmegapolys commentedon Jun 6, 2026
@bbakerman thanks for the update! Though I think this one's still open: the zero-arg
newResult()keeps the non-null bound onmasterandv26.0:public static <T> Builder<T> newResult()— sonewResult<@Nullable T>()doesn't compile under JSpecify.The fix (
<T extends @Nullable Object>) only lives on two unmerged branches (claude/fix-graphql-java-4364-dbdVC,fix/issues-4364-and-4200), and there's no PR for either. Which commit/release actually closes it?bbakerman commentedon Jun 9, 2026
Sorry made an assumption the commits has been merged
hiSandog commentedon Jul 3, 2026
Since the earlier fix was assumed merged, this probably needs a very small Kotlin/JSpecify regression test in addition to the Java signature change. The important case is the zero-arg factory under
@NullMarked, becauseDataFetcherResult.<String>newResult()can still look fine from Java whilenewResult<String?>()fails from Kotlin. A test mirroring #4179/#4180 would make the release boundary for this fix unambiguous.exijn commentedon Jul 17, 2026
Hi, I'd like to work on this issue.
I plan to update the type parameter of the zero-argument
DataFetcherResult.newResult()method to<T extends @Nullable Object>and add a Kotlin regression test verifying thatDataFetcherResult.newResult<MyType?>()compiles correctly.I’ll also check the related factory methods for the same missing nullable bound. Since the existing fix branches have not been merged and there is currently no PR, would it be okay for me to open one?
yonatang commentedon Aug 13, 2026
As @hej090224 said, this will still fail to compile:
This is a walkaround:
But I'd love to see #4418 merged,
newResult<Any?>()is more elegant.