Satisfactory instal the new version for apple

current official imagej-macosx (x86), with current official JRE (x86):Ģ. It works fine with the following behavior when launched from the command line to monitor errors (there's some warnings too regarding patcher/injector, but they seem of no issue):ġ. I've tested this binary on my Apple Silicon M1 Mac. ~/dev/imagej-launcher > lipo -info ImageJ-macosxĪrchitectures in the fat file: ImageJ-macosx are: x86_64 arm64` The project compiled with no issue and the binary is universal: I also had some Java path issues, which may be a Big Sur thing. I made a fork () and tweaked CMakeLists.txt to provide the two arch for cmake (to make a universal binary). This is also supported by cmake, which I was pleased to see is used by the imagej-launcher. It does report an architecture mismatch error and does a fallback to system Java, which results in a 2nd Fiji icon in the dock-minor inconvenience.Īs noted in the thread, Apple docs show you can build for a different architecture than you run (can't test obviously) and can build universal binaries. Non-fat file: ImageJ-macosx is architecture: x86_64 Applications/Fiji.app/Contents/MacOS> lipo -info ImageJ-macosx The existing launcher actually works-despite being x86. (The normal Mac OS install also works fine in Rosetta, but is markedly slower.)

I have Azul 11, but native OpenJDK is also available via homebrew, and use of the 'No JRE' Fiji.

So for Fiji/imagej the key is native JRE. … I've started a image.sc thread regarding getting things to work smoothly *native* rather than in Rosetta emulation.Įverything works when architectures are matched, so everything emulated or everything native.

I've been using Fiji on an Apple Silicon M1 (arm64) MacBook Pro (Big Sur 11.4)

Satisfactory instal the new version for apple