Repository navigation
Conversation
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
mrousavy
added this pull request to stack #2000
October 23, 2026 12:23
mrousavy
changed the title
This was referenced Oct 23, 2026
mrousavy
force-pushed
the
mrousavy/v1-kotlin-ulongarray
branch
from
October 23, 2026 17:36
035e0ad to
8d57d32
Compare
Kotlin exposed UInt64[] as Array<ULong> while JNI carries a long[], so every crossing copied the array and boxed each element. Generated structs copied it again each time C++ read the field. UInt64[] is now ULongArray, a value class over LongArray, and the bridge converts it with asLongArray() and asULongArray(), which reuse the same array. Struct fields hold the long[] that JNI reads directly. UInt64[][] becomes Array<ULongArray>, so only the outer array is mapped. The mapToLongArray helpers in nitro-core have no callers left and are removed. ULongArray still requires opting in to ExperimentalUnsignedTypes, and Kotlin warns without it. The generated +autolinking.gradle opts each Nitro module in, which covers generated code and the module's own spec implementations. ULongArray boxes compare by identity, so generated structs compare these fields through their long[]. New TestObject methods pass UInt64 arrays as parameters, nested and optional arrays, Promise results and callback values.
mrousavy
force-pushed
the
mrousavy/v1-kotlin-ulongarray
branch
from
October 23, 2026 17:51
8d57d32 to
ae0d1bc
Compare
This was referenced Oct 23, 2026
This branch was successfully deployed
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
First of five stacked PRs: #1997 (this one) → #1998 → #1999 → #2008 → #2009.
Kotlin exposed
UInt64[]asArray<ULong>while JNI carries along[], so every crossing copied the array and boxed each element. Generated structs copied it again each time C++ read the field.UInt64[]is nowULongArray, a value class overLongArray. Bridges convert withasLongArray()andasULongArray(), which reuse the same array, and JNI reads struct fields directly because aULongArrayfield is along[].UInt64[][]becomesArray<ULongArray>and only the outer array is mapped.ULongArrayboxes compare by identity, so generated structs compare these fields through theirlong[]. ThemapToLongArrayhelpers in nitro-core have no callers left and are removed.This changes the Kotlin type of every
UInt64[]API fromArray<ULong>toULongArray.ULongArraystill requires opting in toExperimentalUnsignedTypes, and Kotlin warns without it. The generated+autolinking.gradle, which every Nitro module applies, now opts the module in withlanguageSettings.optIn('kotlin.ExperimentalUnsignedTypes'). That covers the generated code and the module's own spec implementations; only other modules that use these APIs, such as the app, need their own opt-in. The arrays docs say so.New
TestObjectmethods passUInt64[]as a parameter, nested and optional arrays, aPromiseresult and callback values, with values above 2^63.Validation: nitro-core, nitro-test and nitro-test-external Kotlin compile without warnings (152 opt-in warnings without the Gradle block), and the changed JNI sources compile with the NDK (syntax only, the Hermes submodule wasn't checked out). I did not run the runtime tests locally.
🤖 Generated with Claude Code