JNI global state and JNI_OnLoad assume a single copy of the runtime per process — statically-linked-per-module embedders (Skip Fuse) end up with N copies and a nil JNI.jni

Context issue, cross-referencing skiptools/skip#716 (full evidence there: symbol counts showing SwiftJNI statically linked into seven .so files with three competing JNI_OnLoad exports, disproven System.loadLibrary workaround, crash signature).

When an embedder statically links the jni-core runtime into more than one .so in the same process — which is what Skip Fuse's per-module linking does today — JNI.jni exists once per object, JNI_OnLoad initialises only the copy in the library the JVM loaded, and the first use from any other copy fatals at SwiftJNI.swift:1390 (String.fromJavaObject).

Probably a build/packaging question more than a bug in swift-java itself, but worth deciding where the invariant lives: should swift-java (a) document "exactly one copy per process" as a hard requirement, (b) expose an explicit re-initialisation / state-sharing hook for multi-.so embedders, or (c) ship the runtime as a dynamically-linkable core so embedders can share it? Happy to test a direction against our reproduction.

Start with SwiftJNI.swift around line 1390 and locate JNI.jni initialization and JNI_OnLoad, then review the linked skiptools/skip#716 reproduction and its symbol counts across the seven .so files. Confirm the multi-module failure and compare the proposed ownership options; done requires an agreed invariant or sharing mechanism validated against the reproduction.