While waiting for an answer, since Steam’s ARM build crashes immediately on launch,I tried to tinker with the standalone client and the help of Mr. GPT and did a full investigation. Here’s a quick recap of everything tested and what I found.
1. Replaced JOGL with 2.5.0 (ARM-native)
I unpacked the Haven client, replaced all JOGL libraries (gluegen-rt.jar, jogl-all.jar, and the macosx-universal natives) with JOGL 2.5.0.
Confirmed that the new ARM-native JOGL libraries load correctly.
2. Cleaned out cached natives
Deleted all jogamp caches under /private/var/folders/... and let them rebuild.
Confirmed that macOS was loading the new 2.5.0 native .dylib files.
3. Tested multiple JVMs
Tried launching with:
• Java 21 (ARM)
• Java 25 (ARM)
Behavior is identical across JDK versions.
4. Crash persists even with correct JOGL setup
The crash now happens consistently in:
- Code: Select all
libnativewindow_macosx.dylib
Java_jogamp_nativewindow_macosx_OSXUtil_DestroyNSWindow0
macOS logs show:
- Code: Select all
Exception Type: EXC_BREAKPOINT (SIGTRAP)
Application Specific Information:
Must only be used from the main thread
This means the client (via JOGL) attempts to destroy or reorder an NSWindow from a non-main thread. On macOS 14+ this wasn’t fatal, but on macOS 15/16 Apple enforces this strictly and immediately traps the process.
5. Key conclusion
Everything loads correctly, but Haven (or the JOGL calls it relies on) performs AppKit window operations off the main thread. macOS 26 kills the process because NSWindow APIs must run on the main thread.
So at this point it looks like an upstream threading issue rather than a JOGL version or JDK configuration problem.