Can Max work with a more recent JVM?
Hi, JVM is gettig better each new version with Vector API on the horizon, https://openjdk.org/jeps/460. But it seems MXJ~ got stuck on JVM1.8. Is there any way to use newer jvm with max? Even a hacky one?
Hi Michal,
I haven't used Java with Max in the last past 5 years or so. But I was curious myself. So I installed Oracle Java 21. Seems to work without a hitch. I could recompile classes, and I have a java class to print the used Java version to the Max console. All seems fine:
I've just got JDK 17 installed, changed JAVA_HOME and even restarted my machine for better effect :)
when I type
echo $env:JAVA_HOME
I get
C:\Program Files\Java\jdk-17
But when I open the 'compile window' Max still thing the compiler is at 'C:\Program Files\Java\jre1.8.0_202/bin/javac.exe' as it used to be before installing JDK17
Does Max has it's own way of locating JDK?
It’s many many years that I had a windows machine. On POSIX systems I would check which Java version is set as default by using “java - version” and checking with executable is actually used with “which java”.
There is also a Java config file. On Mac it’s in the Max.app package. There might be some options there.
I just found this in a README in the embedded max-mxj package:
On Windows, it searches in that order: embedded JRE, on system JDK, on system JRE
The search for an embedded JRE is done in the application, it must be a folder named "jre" placed in the same folder as the application .exe
As there is no embedded JRE in Max since years anymore, it may be something you have to configure to set the system JDK.
this is what I get with java --version
java 17.0.10 2024-01-16 LTS
Java(TM) SE Runtime Environment (build 17.0.10+11-LTS-240)
Java HotSpot(TM) 64-Bit Server VM (build 17.0.10+11-LTS-240, mixed mode, sharing)
but whan I try to run a class buit fro JRE17 I get:
java.lang.UnsupportedClassVersionError: com/nekomatic/max/MxjTestClass has been compiled by a more recent version of the Java Runtime (class file version 61.0), this version of the Java Runtime only r
ecognizes class file versions up to 52.0
at java.lang.ClassLoader.defineClass1(Native Method)
at java.lang.ClassLoader.defineClass(Unknown Source)
at com.cycling74.max.MXJClassLoaderImpl.doLoadClass(MXJClassLoaderImpl.java:117)
at com.cycling74.max.MXJClassLoader.loadClazz(MXJClassLoader.java:88)
Could not load class 'com.nekomatic.max.MxjTestClass'
But I still have JDK 1.8 in the system - I guess I'll remove all apart from 17 and see where it takes me.
after uninstalling all old java version but with JDK 17 still in the system with both PATH and JAVA_HOME sot to it I get the following in Max :(
mxj: could not find Java 2 Runtime Environment.
Error loading:
(mxj) mxj_platform_init failed. Could not initialize the Java Runtime Environment.
Please check your Java installation. http://java.sun.com
Unable to create JVM
I am not sure if Open JDK is supported. Maybe try to uninstall it and and give the Oracle Java a try….
I think I've found where the problem is - from the mxj sources it seems it searches for a JRE path based on some system registry entries..
It seems to be looking for
Computer\HKEY_LOCAL_MACHINE\SOFTWARE\JavaSoft\Java Runtime Environment
but this entry does not exist with JDK alone, Even If I installes an openJRE it added a key
Computer\HKEY_LOCAL_MACHINE\SOFTWARE\JavaSoft\JRE which obviously does not match the above. I hate to fiddle with windows registry but may need to do that in the end...
Oh I successfully suppressed any memories of the windows system registry 🙃
I hope it will work for you!
Maybe installing the runtime on top will work…?
In the mxj sources trhere are still references to a jre location inside the application directory. Lucky they have not use same error string in more places :) https://github.com/search?q=repo%3ACycling74%2Fmax-mxj%20%22could%20not%20find%20Java%202%20Runtime%20Environment.%22&type=code
I tried to fake such location via symlink pointing to an Eclipse version of JRE 21... unfortunately as soon as I created an mxj object the application died without warning....
The conclusion is - I give up! :D
Lucky I use Kotlin for most of my JVM stuff so I'll have no issues with recompiling my code to JRE 1.8