GeezerVison

Description

Stacked on #2093 (base perf/object-lifecycle).

When a JS callback returns a value for a primitive Java return type (onTouch → boolean, getCount → int, …), the result went through the generic converter (JsArgToArrayConverter): a jobject[1] heap allocation, a JNI NewObject of the wrapper, a local-ref round trip, and then the generated binding unboxed it again.

For boolean/int/long/float/double returns, Java now passes a long[2]. When the value maps directly, the native side writes {bits, 1} into it and returns null, and Java boxes it with valueOf. Java→JS argument passing already avoids boxing the same way since #2092.

No behavior change. The fast path only takes the values the converter already boxed into exactly the declared wrapper type, which is all the generated binding's cast accepts. Every other value still goes through the converter unchanged: Number objects, proxies, cast markers, and anything at or beyond ±2^63, where the converter's double→int64 cast is undefined and gives different results on arm64 and x86_64 (so the spec leaves those out). That includes the cases that end in a ClassCastException or a defaulted null today.

To pin that, the first commit adds a spec that captures the current conversion as a matrix: 33 JS values × the 8 primitive return types, each recording the returned value or the exception class.

The matrix shows some existing behavior worth knowing about. This PR keeps all of it, and fixing it would be a separate, deliberate change:

• A double callback returning a whole number (e.g. 1) throws ClassCastException. The converter boxes it as a Long.
• A float callback returning a negative, NaN, infinite or very small value throws ClassCastException. The converter only produces Float within [FLT_MIN, FLT_MAX].
• byte, short and char returns only work through byte()/short()/char() cast markers.
• null, undefined and {} become the type's default value, and new Boolean(false) returns true.

Numbers

Callback benchmarks only, alternating pairs (5 launches each, median ns):

intReturn is ~25% faster in both pairs. The void callbacks don't take the new path; their only change is an extra null JNI argument. They were flat in the first pair, and the second pair ran last as the host started getting busy. A third pair was discarded: another build loaded the host during it, so every row, base included, read 40–100% higher.

Does your pull request have unit tests?

Yes: testPrimitiveCallbackReturns.js, the conversion matrix above. It passes on the boxed path and on the new one. The full suite passes: 1484 specs, 0 failures.

Summary by CodeRabbit

• Bug Fixes
  • Improved conversion of JavaScript callback results to Java primitive return types, including numeric values and booleans. Values that cannot be converted directly continue to use the existing conversion behavior.
  • Added coverage for primitive return types and edge cases, including non-finite numbers and values that cause a class-cast error.