GeezerVison

Description

Two small, independent commits in the JS-to-Java argument marshalling.

1. Remove the unused JSToJavaConverter

test-app/runtime/src/main/cpp/conversions/ (JSToJavaConverter, JNIArgRefsState.h, ConversionConsts.h, CastTypes.h and the primitives/, arrays/ and objects/ converters) is a 2022 rewrite of JsArgConverter that was switched back out the day it landed (b5218c9, "... use this converter again temporarily") and has had no callers since. It was still compiled into libNativeScript.so, and the only references left were commented-out lines in CallbackHandlers.cpp. No live code includes any header from that folder, so the whole folder goes, along with its CMakeLists.txt entries, the commented-out call sites, and a stale mention in docs/knowledge/v8-14-migration.md (the ObjectManager::Link on NIO buffers it describes lives in JsArgConverter).

2. Reuse the cached signature tokens in JsArgConverter

With a resolved MetadataEntry, JsArgConverter copied entry->parsedSig into its own std::vector<std::string> on every Java call: one std::string per parameter per call, and object tokens such as Ljava/lang/String; are longer than the small-string buffer, so each one is a heap allocation. The converter now reads the tokens through a const std::vector<std::string>* that points at entry->parsedSig when the entry is resolved, and at an owned vector only when it has to parse the signature itself (unresolved/null entry, and the RegisterInstance constructor path). Behaviour is otherwise unchanged.

Lifetime: the converter is a stack object that lives for one CallJavaMethod call. entry points into the candidates vector of the method's MethodCallbackData, which the per-isolate metadata cache owns until isolate teardown. candidates is only appended to while the owning class's template is being built, which is finished before any of its methods can be called, so the vector cannot reallocate under a running call. The pointer therefore cannot outlive its target. Because the pointer may refer to the converter's own owned vector, copy construction/assignment are deleted (CallJavaMethod's cond ? JsArgConverter(...) : JsArgConverter(...) initialisation is a guaranteed elision under C++20 and still compiles).

JsArgToArrayConverter has no signature-token vector, so it is unchanged.

Does your commit message include the wording below to reference a specific issue in this repo?

No.

Related Pull Requests

#2061 (fix/proxy-receivers) also touches JsArgConverter.cpp and conversions/JSToJavaConverter.cpp. Whichever merges second needs a trivial rebase: the #2061 hunk in JSToJavaConverter.cpp just goes away along with the file.

Does your pull request have unit tests?

No new tests: this is a removal plus a behaviour-preserving refactor, covered by the existing suite. Built with ./gradlew :app:assembleDebug -Pabis=arm64-v8a -PuseKotlin=true and ran the test app on an API 35 arm64 emulator:

Runtime Tests: SUCCESS: 1253 specs, 0 failures, 4 skipped, 11 disabled in 70.918s.

Summary by CodeRabbit

• Refactor
  • Consolidated JavaScript-to-Java argument conversion across method calls and constructors. Conversion support remains for primitive values, arrays, objects, and Java NIO buffers, including ArrayBuffer, SharedArrayBuffer, and typed-array inputs.
  • Updated the migration guidance for converting JavaScript buffers to Java NIO buffers.