Description
LeveldbJournalNativeSpec fails on Apple Silicon because Pekko currently uses org.fusesource.leveldbjni:leveldbjni-all:1.8, whose macOS native library does not contain an ARM64 slice.
Reproduction
Environment:
- macOS 26.5.1
uname -m: arm64
- Java 25.0.1
Run:
sbt "persistence-tck / Test / testOnly org.apache.pekko.persistence.journal.leveldb.LeveldbJournalNativeSpec"
The same failure is reached from validatePullRequest.
Actual error:
java.lang.UnsatisfiedLinkError: Could not load library
...
fat file, but missing compatible architecture
(have x86_64,i386, need arm64e or arm64)
Root cause
project/Dependencies.scala defines:
val levelDBNative =
"org.fusesource.leveldbjni" % "leveldbjni-all" % "1.8" % "optional;provided"
The bundled macOS library reports:
META-INF/native/osx/libleveldbjni.jnilib:
Mach-O universal binary with 2 architectures: x86_64 i386
It has no arm64 slice.
Workarounds investigated
The HawtJNI property -Dlibrary.leveldbjni.path=<dir> is recognized and attempts to load a library from the supplied directory. However, the ARM library in org.openlabtesting.leveldbjni:leveldbjni-linux64-aarch64:1.8 is a Linux binary:
ELF 64-bit LSB shared object, ARM aarch64
Pointing library.leveldbjni.path at that library on macOS fails with:
slice is not valid mach-o file
The org.openlabtesting.leveldbjni group has four artifacts in Maven Central (leveldbjni-project, leveldbjni, leveldbjni-linux64-aarch64, and leveldbjni-all) and no macOS ARM64 artifact. Its leveldbjni-all:1.8 still bundles the old x86_64+i386 macOS library.
Huawei variants 1.8-hw-20191105 and 1.8-hw-aarch64 also add Linux AArch64 ELF libraries while retaining the old x86_64+i386 macOS library.
Possible direction
These Maven Central artifacts contain a real Mach-O ARM64 library and passed a local JNI open/put/get/close/destroy smoke test:
io.github.tronprotocol:leveldbjni-all:1.18.3
com.halibobor:leveldbjni-all:1.23.2
A replacement needs compatibility review before adoption: these artifacts use a different org.iq80.leveldb API dependency and do not bundle the Windows native DLLs present in the current artifact. A platform-specific test dependency or another approach may be needed to avoid regressions and non-reproducible published POMs.
Expected behavior
The native LevelDB spec should either run successfully on macOS ARM64 with an Apache-compatible supported dependency, or the unsupported platform should be handled explicitly without breaking the full PR validation.
References
Description
LeveldbJournalNativeSpecfails on Apple Silicon because Pekko currently usesorg.fusesource.leveldbjni:leveldbjni-all:1.8, whose macOS native library does not contain an ARM64 slice.Reproduction
Environment:
uname -m:arm64Run:
sbt "persistence-tck / Test / testOnly org.apache.pekko.persistence.journal.leveldb.LeveldbJournalNativeSpec"The same failure is reached from
validatePullRequest.Actual error:
Root cause
project/Dependencies.scaladefines:The bundled macOS library reports:
It has no
arm64slice.Workarounds investigated
The HawtJNI property
-Dlibrary.leveldbjni.path=<dir>is recognized and attempts to load a library from the supplied directory. However, the ARM library inorg.openlabtesting.leveldbjni:leveldbjni-linux64-aarch64:1.8is a Linux binary:Pointing
library.leveldbjni.pathat that library on macOS fails with:The
org.openlabtesting.leveldbjnigroup has four artifacts in Maven Central (leveldbjni-project,leveldbjni,leveldbjni-linux64-aarch64, andleveldbjni-all) and no macOS ARM64 artifact. Itsleveldbjni-all:1.8still bundles the oldx86_64+i386macOS library.Huawei variants
1.8-hw-20191105and1.8-hw-aarch64also add Linux AArch64 ELF libraries while retaining the oldx86_64+i386macOS library.Possible direction
These Maven Central artifacts contain a real Mach-O ARM64 library and passed a local JNI open/put/get/close/destroy smoke test:
io.github.tronprotocol:leveldbjni-all:1.18.3com.halibobor:leveldbjni-all:1.23.2A replacement needs compatibility review before adoption: these artifacts use a different
org.iq80.leveldbAPI dependency and do not bundle the Windows native DLLs present in the current artifact. A platform-specific test dependency or another approach may be needed to avoid regressions and non-reproducible published POMs.Expected behavior
The native LevelDB spec should either run successfully on macOS ARM64 with an Apache-compatible supported dependency, or the unsupported platform should be handled explicitly without breaking the full PR validation.
References