How to use the new Microsoft JRE for Java Apps
Like FreeMind, XMind, and probably others!
I frequently use Mind Mapping tools to help explore problems and solutions, and FreeMind has been my go-to tool for years!
As the name suggests, it’s free, it’s not resource-heavy, and I’ve a fairly extensive set of existing mindmap (.mm) files. I’ve seen many modern free or perpetually-licensed alternatives sink into the black hole of subscription licensing and I’m happy to make do with this old warhorse!
One issue, though, is that it uses the Java runtime, looking for a rather old version of it, and the EXE triggers the installation page each time you run it if it’s not present (say, if you’re experimenting with alternative JREs, or just didn’t install Oracle Java).
Also, if you’re using Actual Java, the startup performance on a Surface Pro X was - how to be diplomatic - not amazing, Java being X86-native, so running Java which is converted to X86 code which was then being translated to ARM… (It’s mostly okay when running). But there’s a better option!
There’s a newish Microsoft Build of OpenJDK and it ships cross-platform (linux, MacOS and Windows) builds of JDKs which include native Java Runtime Environments (JREs) for ARM64/AArch64/M1 platforms.
And my unscientific, first-person fiddling has shown that it’s fast - the performance of the X64 version with the couple of Java based apps I use might be double that of the the JRE those apps ship with/demand. (Songs of Syx is noticeably - like 2-3x - smoother when its JRE is ripped and replaced!). And an ARM-native JRE makes for happy Java apps on Surface Pro Xs…
To date, I’ve been installing the JDK and then manually editing the [HKEY_LOCAL_MACHINE\SOFTWARE\JavaSoft\Java Runtime Environment] registry entries to ensure that the Microsoft JRE was seen as a legitimate Java installation for FreeMind/XMind, but it looks like there’s (now?) an installation switch (FeatureOracleJavaSoft) to take care of that for you. But from some very brief fiddling, it didn’t work from WinGet (with the Winget-supplied MSI installation log claiming not to know of the feature at all), so I’ll ignore it for now.
Here’s how to do it manually, and how I troubleshot v.21 not working! (note for Freemind specifically: if you want it to work, just get and use v.17, don’t try 21).
Install the JDK. I’ll use 21. Why not? (later-me edit: Because it doesn’t work!)
Winget install microsoft.openjdk.21
At this point you should be able to run JAR files directly with your new
C:\Program Files\Microsoft\JDK-version-hotspot\bin\JAVAW.exe, but often not the EXE which wraps them (Freemind.exe still complains, in my case).
To fix EXEs looking for Java installations:Edit the registry paths for Java to reflect the new JRE.
Note: There may not be a JavaSoft key at all, so you may need to create one.
Here’s the .reg file I customize for this:
Windows Registry Editor Version 5.00[HKEY_LOCAL_MACHINE\SOFTWARE\JavaSoft][HKEY_LOCAL_MACHINE\SOFTWARE\JavaSoft\Java Runtime Environment]"CurrentVersion"="21.0.1.12"[HKEY_LOCAL_MACHINE\SOFTWARE\JavaSoft\Java Runtime Environment\21.0.1.12]"JavaHome"="C:\\Program Files\\Microsoft\\jdk-21.0.1.12-hotspot""RuntimeLib"=""
The JavaHome path above needs to be customized based on the installed location of the JDK (you can see how an installer switch would be preferable to do this for you!). You don’t include the bin folder, just the folder containing the bin folder.If you’re typing paths manually into Regedit, path strings here don’t need double-backslashes.
ARM note: On my ARM64 systems, the Microsoft JDK hotspot installs into Program Files (Arm) so that needs to be included in the path above.
Notice that there looks like the intention of a versioned structure - a folder gets created for each version of a JRE, and the top-level JRE “CurrentVersion” value points to the active configuration folder.However, as we’ll soon see, it turns out this might not be how every (especially very old) Java executable wrappers find their version…
Once the registry keys are set up, in Regedit it should look like this:
Moment of truth:
Ah rats! But that’s not the same error as before… The JAR seems to work fine, but the EXE is unhappy for… some reason? And I like having the EXE work, it has a pretty icon and I can directly associate .mm files with it…
I’ll try the v17 hotspot (which is working fine on my ARM machines)
Winget install microsoft.openjdk.17
And then try changing the CurrentVersion string:
No. Same error…
Maybe ProcMon can show us what’s happening (I’ll filter by FreeMind.exe)
Huh. Doesn’t look like a WOW64 thing, but it looks like it’s ignoring the CurrentVersion setting entirely and just heading to… maybe the highest-numbered settings folder?
I’ll rename the 21 key to 11 and see if that makes the EXE work… (naughty!)
And yes, it works!
I wonder how many other EXEs out there are doing a similar thing and failing with later versions installed… Loads of AppCompat fun waiting there I’m sure…
I suspect I could also keep the badly-named registry key and redirect any more modern/compliant/CurrentVersion-compatible Java apps to “11” (really 21) using the CurrentVersion setting…
But there you have it - native, better-performance Java FreeMind on Windows!