PSA: Mirth Connect on macOS Monterey

[segfault802]

Myself and others have encountered issues with Mirth instances crashing on macOS Monterey to the point that it is unusable. The bundled Java included with the launcher appears to work but will crash silently. Other versions will fail to start entirely. The underlying issue seems to be this OpenJDK bug:

https://bugs.openjdk.java.net/browse/JDK-8275723
That's reported to be fixed in OpenJDK 17.0.2, but it doesn't seem to solve this issue, at least not for me.

It does not appear to be specific to M1 macs, I'm on an M1 machine but others have reported it on Intel. The only workaround at the moment that seems to work is to use the Azul Zulu or another alternative JRE or JDK that includes JavaFX.

https://www.azul.com/downloads/?package=jdk
It can also be installed with Homebrew if you use that. I've been using it for a few weeks and it mostly works although there is an issue with some text panes not rendering, most noticeable in the message viewer. Annoying, although sometimes it works.

Update: Came back to this and tried some of the other Java versions mentioned in various comments. Azul Zulu JDK 8.64.0.19 is working for me without any issues. You'll need to get it from their website as Homebrew only has v17.x and that has issues. I tried both the JRE and JDK and both worked, just sure to get the version with Java FX.

Thanks to @skehlet for the tip off 👍

[JawnnyB]

Confirmed that this worked for me on an Intel processor running Monterey. I did have to specify a custom Java Home location in Mirth though. Anyone found a better way to configure that? Happy to share what I tried to help build some step by step instructions for others.

a

[jonbartels]

Anyone found a better way to configure that?

Somewhere in the Launcher install directory is a file called connections.json this contains your information for each connection. You should be able to bulk-edit that file and force a custom JVM.

There may also be launcher config files that will force it.

[JawnnyB]

Much appreciated @jonbartels! I had tried modifying the $JAVA_HOME environment variable directly on my system but came up short. Perhaps someone here can shed some light on what I missed or at least use it to inform their own search.

In Terminal:

/usr/libexec/java_home -V (check existing JDKs/JREs)
$JAVA_HOME (output current JAVA_HOME env variable)
/usr/libexec/java_home -v1.8.0 (make sure this returns the Zulu version. If it doesn't you may need to be more specific in the -v flag)

If $JAVA_HOME has no value --> export JAVA_HOME=$(/usr/libexec/java_home -v "1.8.0")

If $JAVA_HOME has a value -->
unset JAVA_HOME
export JAVA_HOME=$(/usr/libexec/java_home -v "1.8.0")

$SHELL (output if you're using bin/sh or bin/zsh)
source ~/.zshrc (restart profile)
source ~/.bashrc (restart profile)

Again this DID NOT work correctly for me, but I think it's the right idea. Appreciate anyone who can bring this home

[jonbartels]

First - Anything for a fellow JonB :D

Modifying JAVA_HOME won't help you with the Launcher - The Launcher defaults to the "bundled" JVM which is Oracle Java 8. You have to tell the launcher to use a different JVM.

Modifying connections.json will update each connection to use your selected JVM. sed or jq might be appropriate.

pwd ; find ./ -name *.json
/Applications/Mirth Connect Administrator Launcher.app/Contents
.//java/app/data/connections.json

There may also be a flag or other config file to change the Launchers own default.

On a Mac - I like jenv for managing Java installations. Its available on homebrew. https://github.com/jenv/jenv . It won't help you here but its generally handy.

[tonygermano]

I use https://sdkman.io/ on linux, and it's great. I've never used it on a mac, but it is a supported platform.

[skehlet]

M1 Mac on Monterey here. Recently I went through about 10 JVMs to find one that would run the Mirth Connect Administrator without crashing. Confirmed that it must have JavaFX for the Administrator even to launch. I found that the 17.0.2 JDKs from Eclipse, Azul, and Oracle all crashed or had problems.

The one I found that is currently working reliably is Zulu 8.60.0.21 with JRE FX.

I too would like to know how to change the Launcher's own JVM, because it crashes frequently as well.

[segfault802]

Thank you! I had been trying in vain to find something that worked and the closest I'd gotten was the zulufx package from homebrew, but it is version 17. Zulu 8 seems to be working fine for me and I've yet to encounter any of the UI bugs seen in the other version.

[malcomm]

Hi all - I can confirm that the JRE Bundled with Mirth Connect Administrator Launcher (MCAL) was the problem on my system. Here is the version that is bundled:

----> app_java_home: ../../../../Plugins/jre.bundle/Contents/Home/jre
java version "1.8.0_181"
Java(TM) SE Runtime Environment (build 1.8.0_181-b13)
Java HotSpot(TM) 64-Bit Server VM (build 25.181-b13, mixed mode)

For me, I made sure that I had a good version Java installed, I am using Amazon Corretto v8 and v17. Make sure that your system is set to use these via JAVA_HOME or some like jenv.

As @JawnnyB pointed out, you just need to launch Mirth Connect from Mirth Connect Administrator Launcher using the Default or Custom options. Default worked for me.

As an alternative you can delete the JRE that is bundled with MCAL. I deleted:

/Applications/Mirth Connect Administrator Launcher.app/Contents/PlugIns/jre.bundle/

Now when I run Mirth Connect with the Default option on Java Home setting MCAL is smart enough to find the correct Java.

---

I do believe that a new version of Mirth Connect Administrator Launcher should be released with an updated bundled java; 1.8.0_333 or later.

[siddharthsharma9258]

I also tried to install mirth on M1 Macbook Air, Monterary.

I downloaded the MacOS installer directly from nextgen website, but when I run it, Mac says cannot run security scan on the app. I have no idea why it would say that. Basically, it won't run.

Then I tried tar.gz, it also said that jar publisher cannot be verified. Not sure what to do.

[malcomm]

@siddharthsharma9258 - try to open it from finder using control-click. More instructions:

Open a Mac app from an unidentified developer

Or: If you can’t open an app on Mac

[siddharthsharma9258]

But why is the developer unidentified. It's nextgen right?

[siddharthsharma9258]

You get the same message?

[ghost]

Just moved over to a Mac with M1 pro chipset. Trying to get Mirth Connect to stop crashing randomly. Read through the post and have installed both zulu-8.jdk and .jre. Installed default location (/library/java/javavirtualmachines) When I run java -version in terminal I get openjdk version "1.8.0_332", OpenJDK Runtime Environment (Zulu build 1.8.0_332-b09) OpenJDK 64-Bit Server (Zulu Build 25.332-b09, mixed mode)

When I point Connect Administrator to use Java Home/Custom and point it to the Zulu folder I get an error after logging in saying there is an error connecting to the server, please verify server is up and running.

If I set it back to default I can log in with no issues but the connect will just suddenly close without any reason and at random times. Wondering what I am missing.

[jonbartels]

Did you get Zulu With JavaFx?

When you launch MC with either Java Home what java version does the console show when the MC Client starts? This is the "Show Console" option in the Admin Launcher.

On my Mac on M1 on Monterey I have /Library/Java/JavaVirtualMachines/zulu-11.jdk/Contents/Home

My console shows:

Using JRE version 11.0.15+10-LTS OpenJDK 64-Bit Server VM
Java home directory = /Library/Java/JavaVirtualMachines/zulu-11.jdk/Contents/Home
User home directory = /Users/jonathan.bartels
----------------------------------------------------
c:  Clear console window
s:  Dump system properties
----------------------------------------------------

[ghost]

I did install the JRE FX version first and then the JDK second as just the JRE didn't appear to resolve the issue.

Using JRE version 1.8.0_332-b09 OpenJDK 64-Bit Server VM
Java home directory = /Library/Java/JavaVirtualMachines/zulu-8.jdk/Contents/Home/jre
User home directory = /Users/jpallas

c: Clear console window
s: Dump system properties

My custom path is: /Library/Java/JavaVirtualMachines/zulu-8.jre

I get the same error even if I switch to the jdk folder. After entering credentials and trying to login the console returns this (thanks for the tip on how to see error messages with the console option)

Using JRE version 1.8.0_332-b09 OpenJDK 64-Bit Server VM
Java home directory = /Library/Java/JavaVirtualMachines/zulu-8.jdk/Contents/Home/jre
User home directory = /Users/jpallas

c: Clear console window
s: Dump system properties

java.lang.UnsupportedClassVersionError: javafx/application/Platform has been compiled by a more recent version of the Java Runtime (class file version 54.0), this version of the Java Runtime only recognizes class file versions up to 52.0
at java.lang.ClassLoader.defineClass1(Native Method)
at java.lang.ClassLoader.defineClass(ClassLoader.java:757)
at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:142)
at java.net.URLClassLoader.defineClass(URLClassLoader.java:473)
at java.net.URLClassLoader.access$100(URLClassLoader.java:74)
at java.net.URLClassLoader$1.run(URLClassLoader.java:369)
at java.net.URLClassLoader$1.run(URLClassLoader.java:363)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:362)
at java.lang.ClassLoader.loadClass(ClassLoader.java:419)
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:352)
at java.lang.ClassLoader.loadClass(ClassLoader.java:352)
at com.mirth.connect.client.ui.Frame.(Frame.java:237)
at com.mirth.connect.client.ui.Mirth.(Mirth.java:56)
at com.mirth.connect.client.ui.LoginPanel$8.handleSuccess(LoginPanel.java:538)
at com.mirth.connect.client.ui.LoginPanel$8.doInBackground(LoginPanel.java:445)
at com.mirth.connect.client.ui.LoginPanel$8.doInBackground(LoginPanel.java:416)
at javax.swing.SwingWorker$1.call(SwingWorker.java:295)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at javax.swing.SwingWorker.run(SwingWorker.java:334)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at java.lang.Thread.run(Thread.java:750)

[joshmc82]

One thing I tried was replacing the bundled JRE with the Zulu version. I had to open the contents of the package and find the JRE folder, then replace with the new one. IDK if that will help, but maybe worth a shot.

[gmartelly-suki]

@zpjpallas I ended getting it working by installing the full JDK FX, not just the JRE as was suggested above. The version that worked for me is Azul Zulu: 8.62.0.19. Here is how it looks on the site:

Let us know how it goes.

[twest-mirthconnect]

@narupley @pladesma @joaryche - Any thoughts about this?

[joshmc82]

I believe the source of this issue is the Admin Launcher (possibly Mirth Connect Server also) comes bundled with the official Oracle 8 JDK (the version before all of the Oracle license changes) and that conflicts with newer versions of MacOS. Now that OpenJDK is officially supported, a newer Java version should be bundled. In addition, the new Mac silicon (M1 and M2) chips have to emulate x86 architecture but there is a native JDK build for the ARM architecture used by these new chipsets.

It would be ideal if Nextgen would update their bundled Java version as well as offer M1-specific builds for both Mirth Connect and the Launcher instead of requiring users to go through extra steps.

[SSpeer]

I just got a new M1 MBP (Apple is no longer selling Intel based Macs) and am having issues installing MC. I've installed both of the above versions of Java but still am unable to get past the notice that pops up stating that I "need at least a 1.8 Java Virtual Machine to install Mirth Connect Installer. Please download it from http://java.com".

Any thoughts on how to install Java and then MC on a new M1? This is a real pain and can't stand the thought of slinking back to Windows.

Thx!

[siddharthsharma9258]

hehehe.. it's linux anyway behind the scenes.

[joshmc82]

You cool people and your fancy new machines.

Drink the Kool-Aid. It is quite tasty :-)

[siddharthsharma9258]

@joshmc82 - How did you get past that error? I added firewall rule also added an exception to https://localhost:8443 in Java under system preferences.

ERROR 2022-10-12 21:55:19,646 [Codebase Downloader Thread] com.mirth.connect.client.launcher.MirthClientLauncher: java.lang.Exception: Unable to retrieve payload from HTTP request. URI: https://localhost:8443

It's like an itch in the brain I cannot scratch.

[joshmc82]

This may sound like a stupid question but do you have a Mirth Connect server running locally? Can you navigate to http://localhost:8080/ from a browser? What you have downloaded currently is just the Admin launcher. You still need a server to connect up to somewhere.

[siddharthsharma9258]

Finally. I am inside mirth. 👍

Thanks @joshmc82

[ipavlic]

I am hitting two issues:

1. If I download the tarball and run /.launcher from the console, I get the Gatekeeper preventing java libraries from being launched
2. If I download the installer and try to start it, I get the least a 1.8 Java Virtual Machine to install Mirth Connect Installer message

I have the suggested Azul version installed and set.

[jonbartels]

Try this: Find the mirth-launcher JAR in the application directory and run it with java -jar mirth-launcher.jar . Make sure the java you use is Azul.

It's not a great workaround but it will work.

The other thing I do is to use the MCAL installer but install it to ~/Applications instead of /Applications . This avoids needing root access.

Finally MCAL 1.3.0 has a milestone with a fix for MacOS ticketed and in the pipeline. This should help but there is no release date announced yet.

[joshmc82]

This is because it still uses the bundled JRE to launch when you do it that way. Navigate to your install directory via command line, then run java -jar mirth-client-launcher.jar.

[ipavlic-pointcare]

@jonbartels I can confirm that running with java works without security prompts. The installer hangs when (*) I accept the agreement is toggled.