[BUG] MCAL 1.3 Frequent Crashes on macOS Monterey about connect HOT 4 CLOSED

@narupley yep, here's what I ran specifically to set the environment var:
echo 'export INSTALL4J_JAVA_HOME=/Users/josh/.sdkman/candidates/java/current' >> ~/.zshenv
When I open a new terminal, I can run printenv to show all of the environment vars set.
It would be nice to have it just use the JVM at JAVA_HOME (if set). That would more or less avoid all of the issues.

from connect.

Update: if I edit the launcher script in a text editor and uncomment the line for INSTALL4J_JAVA_HOME_OVERRIDE and set it to the same path as my JAVA_HOME environment variable used by the OS, it works fine. Note that setting an environment variable on the OS for INSTALL4J_JAVA_HOME does nothing and it will still use the bundled JRE and crash.

from connect.

If you're setting an environment variable on macOS, make sure you're actually setting it for all shells. Just exporting an env var in a terminal window won't do it, you'd need to add it to like bash_profile or something.

Before release we had multiple people test it out on Monterey+ without any issues... but clearly there are still some moles left to whack.

My best guess is that it's an aarch64 issue, not a Monterey issue. We know there are things to iron out there still, like replacing what JRE is bundled with the app!

from connect.

My best guess is that it's an aarch64 issue, not a Monterey issue. We know there are things to iron out there still, like replacing what JRE is bundled with the app!

The log files say vm_info: Java HotSpot(TM) 64-Bit Server VM (25.181-b13) for bsd-amd64 JRE (1.8.0_181-b13), built on Jul 7 2018 01:02:31 by "java_re" with gcc 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2336.11.00) so it's definitely the x86-64 build of the JVM. I would say this is likely to be a JVM bug or a bad interaction between this JVM and Rosetta on the aarch64 platform. The best Mirth could do (in the short-term) would be to upgrade to the latest hassle-free-license Java 1.8 JVM and see if this crash stops happening. Better yet, switch to an aarch64 JVM which would also necessitate a major upgrade of the JVM version which might be risky.

from connect.