This mod failed to start on MacOS with Forge 47.4.16 for Minecraft 1.20.1

[quantumMAYA]

minecraft-exported-crash-info-2026-02-15T15-26-24.zip
Operating System: macOS (Apple M4 Pro)
Java Version: 17.0.13 (Oracle Corporation)
Minecraft Version: 1.20.1
Forge version: 47.4.16
Launcher: HMCL 3.6.11.265

Burningwave encountered an exception while attempting to obtain the implementation of the JVM internal function (GetDeclaredFieldsFunction). The report mentioned jvm architecture: x64, but the actual system is Apple M4 Pro (aarch64) architecture.

[legionalt]

Running into the exact same issue on Apple M1 as well

[foontinz]

I have a fix for that, will post on that soon today

[foontinz]

Dug into this on Apple Silicon recently. Leaving findings + a workaround here.

-- TL;DR --

Not a TIL bug — it's upstream org.burningwave:jvm-driver. Nothing you can fix here without a burningwave release that doesn't exist yet. There's a workaround that needs zero code changes anywhere.

Root cause

TIL 0.4.7 transitively bundles org.burningwave:jvm-driver:8.19.1 (verified by SHA-1 of the bundled NativeExecutor.class against Maven Central). The bug is two-part:

1. Missing native build — the jar contains libNativeExecutor-{aarch64.so, x32.so, x64.so, x64.dylib} plus Windows DLLs, but no libNativeExecutor-aarch64.dylib (Mach-O ARM64).
2. Wrong filename in the loader — on aarch64 macOS, org.burningwave.jvm.util.Libraries.loadFor() requests libNativeExecutor-aarch64.so (the Linux ELF) instead of a .dylib. So even if upstream added a Mach-O dylib, the loader wouldn't ask for it.

dlopen() then tries to parse a Linux ELF as Mach-O and throws slice is not valid mach-o file, which cascades up as the NoClassDefFoundError: StaticComponentContainer everyone sees.

Workaround (no code patches needed)

macOS dlopen() reads file format from the magic bytes, not the filename extension. So a Mach-O dylib named .so loads cleanly on macOS. This means we can fix the bug by compiling the upstream C++ source for arm64 and slotting it into the existing .so path the broken loader requests:

git clone --branch jvm-driver-8.19.1 --depth 1 https://github.com/burningwave/jvm-driver.git
cd jvm-driver/native
JAVA_HOME=$(/usr/libexec/java_home -v 17)
clang++ -O3 -fPIC -dynamiclib -arch arm64 -std=c++11 \
    -I"$JAVA_HOME/include" -I"$JAVA_HOME/include/darwin" \
    src/main/c-c++/org/burningwave/jvm/NativeEnvironment.cpp \
    src/main/c-c++/org/burningwave/jvm/NativeExecutor.cpp \
    -o libNativeExecutor-aarch64.dylib

The C++ source is purely portable JNI (zero #ifdef __APPLE__ etc.) and Apple clang++ targets arm64-apple-darwin natively. Then drop the resulting Mach-O into the jar at the .so slot:

cp libNativeExecutor-aarch64.dylib stage/org/burningwave/jvm/libNativeExecutor-aarch64.so
(cd stage && zip -f ../theimpossiblelibrary-0.4.7.jar org/burningwave/jvm/libNativeExecutor-aarch64.so)

Apple Silicon Mac clients only — don't ship this patched jar to Linux/Windows, since their dlopen would (correctly) reject a Mach-O at the ELF slot.

Verified on Apple M5 Pro / OpenJDK 17, connected to a real Forge 1.20.1 server with Music Triggers audio working in-game.

Smoke test

public class TilSmokeTest {
    public static void main(String[] args) throws Exception {
        Class.forName("org.burningwave.jvm.NativeExecutor");
        Class.forName("org.burningwave.core.assembler.StaticComponentContainer");
        System.out.println("OK");
    }
}

java -cp ".:theimpossiblelibrary-0.4.7.jar" TilSmokeTest          # crashes
java -cp ".:theimpossiblelibrary-0.4.7-patched.jar" TilSmokeTest  # prints OK

Going to file the upstream PR — source compiles cleanly, binary is built, Maven profile is straightforward.