Skip Fuse duplicates swift-java's JNI runtime across module .so files, leaving its global handle nil at runtime

[luisquin-noma]

Environment

• Skip CLI 1.9.5 (Homebrew), skip-fuse 1.0.2, skip-bridge (0.x)
• Swift 6.3.3, Swift Android SDK swift-6.3.3-RELEASE_android, NDK r27d
• Xcode 26.5, macOS 15 / arm64
• Native/fused mode app, multi-module package
• Third-party JNI dependency: frameo-net/swift-okhttp 0.1.1, which is built on swiftlang/swift-java 0.4.2 / swift-java-jni-core 0.5.1

Symptom

A Skip Fuse app that calls into any swift-java-generated wrapper crashes on the first bridged call:

F SwiftRuntime: SwiftJNI/SwiftJNI.swift:1390: Fatal error: Unexpectedly found nil
  while implicitly unwrapping an Optional value
F libc    : Fatal signal 5 (SIGTRAP), code 1 (TRAP_BRKPT)

Line 1390 is JNI.jni.withEnv { ... } inside String.fromJavaObject — swift-java's
global JNI handle is nil.

The app itself builds, links and launches correctly; the Gradle app build honours the
module's skip.yml dependency block, so the Java classes the wrapper needs are on the
classpath (an earlier ClassNotFoundException disappeared once that was declared).

It is not a missing JNI_OnLoad

swift-java initialises that handle in JNI_OnLoad, which the JVM invokes only for
libraries it loads itself. The obvious theory is that Skip's loader bypasses it, so we
forced the load from Kotlin in AndroidAppMain.onCreate():

for (lib in listOf("SwiftJava", "SwiftJNI", "FormsAPI")) {
    try { System.loadLibrary(lib); logger.info("ok: $lib") }
    catch (e: Throwable) { logger.info("failed: $lib -> $e") }
}

All three load successfully — so JNI_OnLoad does run — and the crash is
unchanged.

Analysis: the runtime is duplicated across module .sos

llvm-nm over the merged native libs shows SwiftJNI statically linked into seven
separate shared objects:

libSkipUI.so            4859 symbols
libSwiftJNI.so          1766
libSkipBridge.so         705
libSkipAndroidBridge.so  385
libFormsAPI.so           125
libFormsDemo.so           72
libSkipFuseUI.so          24

and three of them export their own JNI_OnLoad:

libFormsAPI.so:   T JNI_OnLoad   (alongside $s9SwiftJava0aB11_JNI_OnLoad...)
libSkipBridge.so: T JNI_OnLoad
libSwiftJava.so:  T JNI_OnLoad

So each .so carries its own copy of SwiftJNI's global state. The JVM initialises
whichever copy belongs to the library it loaded; the copy that libFormsAPI.so's code
actually reads is a different instance and stays nil. No single initialisation — forced or
otherwise — can cover them all.

This looks like the runtime counterpart of #714: there, static-library duplication across
Skip's dynamic bridge products became a hard error under Swift 6.4's SwiftPM; here the same
duplication is silent at build time and fatal at runtime, because the duplicated library
happens to own process-global state.

Impact

Any Skip Fuse module that depends on a swift-java-based package is affected, since
swift-java is the standard way to wrap a Java library for Swift on Android. In our case
this blocks using swift-okhttp as an HTTP transport for a Swift OpenAPI client — the
generated client and its DTOs work correctly under Fuse (including polymorphic oneOf
types bridged to Kotlin), and only the transport fails.

Suggested direction

Link swift-jni / swift-java once and share it — e.g. force it dynamic (the same
SKIP_BRIDGE product gate skip-lib already uses) so a single copy of its globals exists
per process, rather than statically embedding it into every module .so.

More generally: any third-party Swift package with process-global state that is initialised
from JNI_OnLoad will break the same way under the current per-module linking, so a
documented rule about what Skip Fuse can and cannot statically duplicate would help.

Reproducing

Minimal shape:

1. skip init --native-app project.
2. A module depending on .product(name: "OpenAPIOkHttp", package: "swift-okhttp", condition: .when(platforms: [.android])).
3. Declare implementation("com.squareup.okhttp3:okhttp:5.3.2") in that module's skip.yml.
4. Call OkHttpClient() from Swift on launch.

Happy to share a reproducer repo or run further diagnostics if useful.

[luisquin-noma]

Two updates from the same codebase since filing.

1. A workaround exists, which narrows the issue rather than closing it. We replaced the swift-okhttp transport with one going through Skip's own bridging: a transpiled (Lite) module wraps OkHttp in Kotlin behind a primitives-only API (send(url:method:headers:body:) -> (status, headers, body)), and a native-side ClientTransport adapter delegates across the Fuse↔Lite boundary. That works end-to-end on the emulator (real HTTP call, response decoded, UI rendered). So apps can route around the duplication — but any third-party swift-java-based library remains unusable under Fuse, which is the ecosystem cost described in the original report.

2. The same fatal signature reproduces WITHOUT swift-okhttp in the graph — the duplicated runtime appears to affect Skip's own bridge on error paths. With swift-okhttp fully removed from Package.swift, an error thrown by a native-side ClientTransport on its first call — before any other bridged call had run in the process — crashed identically:

F SwiftRuntime: SwiftJNI/SwiftJNI.swift:1390: Fatal error: Unexpectedly found nil
  while implicitly unwrapping an Optional value

The same throw propagates and renders correctly if any trivial bridged call (a sync ping into the Lite module) runs first. Deterministic in both directions; we bisected it explicitly (five one-variable runs). Given that skip-bridge builds on swift-java-jni-core, this looks like the same per-.so state duplication biting a copy that only error paths touch before initialisation — which would make this issue about Skip's own runtime layout, not only about third-party swift-java libraries.

We can extract a minimal reproduction for either point on request (the second one needs ~3 files: a bridged Lite module, a native caller that throws before the first crossing, and a skip init --native-app shell).

--

Related: #717 — a separate hang in skip android test --apk with the same package shape (a bridged transpiled module in the graph), found during the same investigation.

[marcprux]

The potential for duplication of static libraries does exist and could lead to the error, but I don't think the diagnosis is quite right.

I believe the confusion lies in the fact that Skip has its own skiptools/swift-jni library that pre-dates swift-java's JNI (that lives in swift-java-jni-core). We eventually want to merge the two so that there's only a single JNI, but work on that has stalled (see skiptools/swift-jni#5). For the time being, there are two separate independent (and functionally nearly identical) JNI shims, each with their own separate JNI classes with a static variable holding the initialized state. Aside from being ugly, there's nothing inherently illegal about this: they should be able to happily co-exist in the same process. And, indeed, there are other Skip apps that successfully rely on SwiftJava as well.

In the case of a Skip app, we manually initialize our own JNI in SkipBridge's JNI_OnLoad, which is manually instantiated from the Main.kt for the app. However, that just initialized Skip's own JNI, and not swiftlang/swift-java-jni-core's JNI (which we know nothing about). I'm not sure why libFormsAPI.so (which I assume is your own library) has the JNI_OnLoad symbol, unless you implement it yourself somewhere, but it shouldn't be coming in from static linkage to either libSwiftJava.so (which is .dynamic) or Skip's libSwiftJNI.so (which is also .dynamic).

All that being said, your for (lib in listOf("SwiftJava", "SwiftJNI", "FormsAPI")) { code should have initialized both the JNI instances, but you say the crash is unchanged. I'm not sure why that is. Can you try once more and make sure that the when you do this, the crash is exactly the same as the one you report?

[luisquin-noma]

(...)
All that being said, your for (lib in listOf("SwiftJava", "SwiftJNI", "FormsAPI")) { code should have initialized both the JNI instances, but you say the crash is unchanged. I'm not sure why that is. Can you try once more and make sure that the when you do this, the crash is exactly the same as the one you report?

Following up with the deeper dive you prompted — you were right to push back on the diagnosis. Three corrections and one new result.

1. The "seven copies of global state" claim is withdrawn. Re-running the symbol inspection properly (llvm-nm --defined-only + demangling) shows the storage for Skip's global — static SwiftJNI.JNI.jni, $s8SwiftJNI0B0C3jniACSgvpZ — exists exactly once in the whole app: [B] in libSwiftJNI.so, defined nowhere else. The per-module "SwiftJNI symbols" our original count picked up are each module's own bridging glue whose manglings mention SwiftJNI types (conformance thunks, private Java_class caches, inlined/specialized code) — not copies of the runtime. The original count didn't separate defined-vs-referenced, nor demangle. Sorry for the noise.

2. The libFormsAPI.so JNI_OnLoad mystery, solved. In the okhttp-era build it sat next to $s9SwiftJava0aB11_JNI_OnLoad... — i.e. it was swift-java's own implementation, statically embedded into our module via the swift-okhttp dependency chain. In the current okhttp-free build, only libSkipBridge.so and libSwiftJava.so define JNI_OnLoad, exactly as you'd expect. Note this cuts against the expectation in your reply: libSwiftJava.so being .dynamic did not prevent its code (including JNI_OnLoad and, presumably, its JNI global) from also being statically embedded into a consumer .so under the skipstone build — which would have meant two copies of swift-java's state in that era's APK. That narrower version of the duplication claim may still be worth a look on your side.

3. Our System.loadLibrary workaround test proved less than we claimed. The forced list was SwiftJava, SwiftJNI, FormsAPI — never SkipBridge, which is the only library that defines Skip's JNI_OnLoad. libSwiftJNI.so defines none, so System.loadLibrary("SwiftJNI") triggers nothing — incidentally, the doc comment in SkipBridge/System.swift ("this needs to be manually loaded with System.loadLibrary(\"SwiftJNI\") in order to have JNI_OnLoad called") may want updating on that point. So "JNI_OnLoad ran and the crash was unchanged" was only ever established for swift-java's handle, not Skip's.

4. Per your request we re-ran — and the crash no longer reproduces at all. We rebuilt the exact commit that crashed, from a pristine git worktree, on a freshly-booted emulator: the same first-call error path now renders the error normally instead of dying. Everything we reported (deterministic across many runs at the time) happened on a long-lived emulator instance with the app repeatedly upgraded in place — and we have since noticed that Gradle's merged_native_libs carries orphan native libs from earlier dependency graphs (libSwiftJava.so is still being packaged today even though nothing DT_NEEDs it; libs dropped from the graph never get cleaned out of the intermediates). So the honest status is: the fatal at SwiftJNI.swift:1390 was real and repeatable when reported, but we can no longer distinguish between (a) stale-native-lib contamination in the packaged APK, (b) emulator/app-upgrade state, or (c) a startup race between the Kotlin-side SkipBridge load and a first native→Java String conversion on an error path. If it recurs we will capture the crash-buffer backtrace (adb logcat -b crash) — which, we now realize, we never had; only the logcat fatal line.

Unaffected by all of the above: #717 (the --apk hang) still reproduces.

Happy for this issue to be retitled, recast or closed as you see fit. The two small actionable bits we see for Skip are the System.swift doc comment above, and — if you can confirm it's general — the orphan-lib carryover in merged_native_libs.

[luisquin-noma]

(...)

4. Per your request we re-ran — and the crash no longer reproduces at all. We rebuilt the exact commit that crashed, from a pristine git worktree, ...

Update — this supersedes point 4 of my previous comment. That re-run was at the rework-era commit (transport over Skip's own bridging), where the crash indeed no longer occurs. We then went one era further back, to the okhttp-era commit from the original report, in a pristine worktree: there the crash reproduces deterministically, and this time we have the backtrace, the mechanism, and an intervention experiment that fixes it in both directions.

Short version: it was never state duplication — it is JNI_OnLoad shadowing, and a single System.loadLibrary("SkipBridge") fixes everything, including the original swift-okhttp transport.

The crash-buffer backtrace: the fatal happens inside Skip's own bootstrap, before any app code runs:

#47 forms.demo.AndroidAppMain.onCreate
#42 skip.foundation.ProcessInfo$Companion.launch          (Kotlin)
#15 skip.android.bridge.AndroidBridge$Companion.initBridge (Kotlin)
#10 AndroidBridgeBootstrap$Companion.initAndroidBridge     (Kotlin → JNI)
#03 SkipAndroidBridge bootstrap (native)
#02 String.fromJavaObject (SwiftJNI)   ← JNI.jni nil → SwiftJNI.swift:1390

Clean symbol data (llvm-nm --defined-only, demangled) for that build:

• Skip's global state (static SwiftJNI.JNI.jni) exists once: [B] in libSwiftJNI.so. No duplication on Skip's side — the original "seven copies" count was bridging glue whose manglings mention SwiftJNI types, as corrected above.
• swift-java, however, is statically embedded into our module despite being .dynamic: libFormsAPI.so defines 6631 SwiftJava* symbols (more than libSwiftJava.so itself, 5604), including its own T JNI_OnLoad and duplicated state (static SwiftJava.JNI.shared [B/D] and JavaVirtualMachine.sharedJVM [B] are defined in both libFormsAPI.so and libSwiftJava.so).

The mechanism: ART invokes exactly one JNI_OnLoad per System.loadLibrary, resolved by dlsym over that library and its dependency tree. This graph contains three JNI_OnLoad definitions (SkipBridge's — the only one that sets Skip's JNI.jni — plus swift-java's in libSwiftJava.so and the embedded copy in libFormsAPI.so). Every library the bootstrap and our old forced-load list actually loaded resolved to a swift-java JNI_OnLoad, so Skip's never ran, JNI.jni stayed nil, and the first String conversion in initAndroidBridge fataled. This is exactly the trap your SkipBridge/System.swift comment warns about ("a dynamic library that loads another dynamic library will not have JNI_OnLoad automatically called") — it just needs one more clause: and if another library in the resolution path defines its own JNI_OnLoad, Skip's loses the race.

The intervention experiment: adding one line before the bootstrap —

System.loadLibrary("SkipBridge")

— and the crash is gone. Better: the entire original swift-okhttp transport now works end-to-end on the emulator — real HTTP through OkHttp via swift-java, oneOf decoded from the wire, UI rendered. So your instinct was right on both counts: the two shims do coexist happily in one process (even with swift-java's state duplicated by the embedding, since each copy's JNI_OnLoad runs), and the diagnosis was wrong — the only thing that was ever missing is a guarantee that Skip's initializer actually runs.

It also explains our disproven workaround: none of the three libraries in the forced list resolves to Skip's JNI_OnLoad, so it could never initialise JNI.jni.

Actionable, both small:

1. Skip's Android bootstrap could System.loadLibrary("SkipBridge") explicitly (or invoke its init directly) rather than relying on JNI_OnLoad resolution winning against whatever else is in the graph. That would make any swift-java-based dependency (swift-okhttp included) work under Fuse out of the box.
2. The System.swift doc comment (it currently names "SwiftJNI" as the library to load, which defines no JNI_OnLoad).

The skipstone static embedding of a .dynamic product (point 2 of the correction above, now with the state globals confirmed duplicated) is arguably a separate, lower-priority issue — benign once initialisation is guaranteed, but it doubles runtime state and code that you'd expect to be shared.

Happy to share the worktree diff / minimal repro for any of this.