RFC: replace abandoned jsc-android with a maintained JSC (Bun's WebKit fork) on Android #186

Problem

Android JSC support in JsRuntimeHost rides on jsc-android (org.webkit:android-jsc), which is effectively abandoned:

• The build we consume (250231.x / 250230.x) is WebKit SVN r250230, dated 2019‑09‑23 — a ~6‑year‑old JSC.
• Last npm publish was ~2 years ago. React Native moved its default engine to Hermes and, as of RN 0.79, split JSC into a separate package — the original react-native-community/jsc-android-buildscripts is dormant.
• No active maintainer, corporate sponsor, or community is shipping updates.

Concrete impact, hit during the N‑API v7 work (#185 / the v7 track): this JSC has no BigInt — its parser rejects 0n literals outright — so JSC can't reach N‑API v6/v7 or JS‑language parity with V8 on Android. We had to feature‑detect‑fail BigInt (ENOTSUP) on Android‑JSC. Every future JS/N‑API feature gap repeats this.

Proposal

Adopt a modern, actively‑maintained JSC on Android and retire the 2019 jsc-android.

Primary candidate: Bun's JSC — Bun tracks a current JavaScriptCore via its oven-sh/WebKit fork and release‑builds it continuously, so it stays current on language + JSC C API surface. bun already builds an N-API compatible runtime on top of this JSC, so it would seem to serve our purposes very well.

possible caveat: Bun has an old issue that declined first‑party Android support, and oven-sh/WebKit officially targets macOS/Linux/Windows. But their releases post Android aarch64/x64 build artifacts, and its demonstrably cross‑compilable to Android aarch64 as the community has proven: opencode-termux project cross‑compiles Bun + WebKit/JSC for Android (ICU 75.1 + WebKit/JSC aarch64) and enumerates the patch set required (Bionic stubs, TLS alignment, if(ANDROID) guards). So the work is: try and use oven-sh/WebKit's prebuilt JSC for our Android ABIs and package it as a drop‑in jsc-android replacement exposing the same C APIs JsRuntimeHost already targets. if we want to slim down the binary size with variants (noJIT / no-intl), then we'd need to produce separate builds (or upstream a change to bun so they publish those variants .

Alternative I evaluated first: @react-native-community/javascriptcore — the JSC package RN 0.79+ split out. I submitted a PR to update JSC (using bun's fork) and had intermittent contact with the maintainer who has since gone silent. We could fork jsc-android-buildscripts and publish to a different namespace, but I personally feel like there's more value/uplift to the global JS community by pitching in with Bun directly.

Why this unblocks us

• N‑API v6/v7+ parity between JSC and V8 on Android (BigInt, and whatever's next).
• JS language‑feature parity — removes the "works on V8, throws on Android/Linux JSC" cliff. (and macOS < 15)
• A publishing channel that's actually maintained, so we're not permanently pinned to 2019.

Open questions / scope

• C‑API surface: I confirmed oven-sh/WebKit exposes the JSC C API (JSContextRef, JSValueRef, JSObjectRef, and the BigInt C API) we compile against.
• ABI coverage: arm64-v8a (+ x86_64 for emulators); binary size vs jsc-android. It all looks like it's there in Bun's github releases, but we need to test integration
• Build/CI: Bun ships a .zip of the .a files, not an AAR . still, the Android patch set the community already mapped this out ahead of us, packaging likely uses FetchContent/prebuilt and we don't need to (cache) build from source.
• Validation: run the N‑API conformance suite (Add N-API compliance tests #116) — test_bigint should pass for real on Android‑JSC instead of the ENOTSUP fallback and no JS polyfill eval in the loop slowing things down.

Surfaced from the N‑API track: #116, #183, #185.