At startup VisualVM picks a JDK that it then decides it won't/can't run with
At startup VisualVM picks a JDK that it then decides it won't/can't run with.
Steps to reproduce the behavior:
- VisualVM 2.0.6 and macOS BigSur (Had the same problem before with other versions)
- Have Java 1.6, 1.8, 11, 15 and 16 installed.
- When starting VisualVM will choose Java 16 to run with (since it the latest...)
- Since Java 16 is unsupported it will then refuse to run...
a) There are 5 JDK:s available – 3 of which should work perfectly (fully supported). Why not pick one of those 3?
b) Why refuse to run with Java 16? Are you sure it won't work?
c) I have found and modified the visualvm_jdkhome property in /Applications/VisualVM.app/Contents/Resources/visualvm/etc/visualvm.conf I shouldn't have to do this, but if I need/want to change some settings it would be preferable from ~/Library/Application Support/VisualVM/2.0.6/config
We plan to support JDK 16 in the next release of VisualVM. If you want, you can start VisualVM 2.0.6 on Java 16 using
visualvm -J-Dorg.graalvm.visualvm.modules.startup.DisableStartupCheck=true
This disables the JDK version check for unsupported JDK.
You don't need to modify the visualvm_jdkhome property in /Applications/VisualVM.app/Contents/Resources/visualvm/etc/visualvm.conf, create a file: ~/Library/Application Support/VisualVM/2.0.6/etc/visualvm.conf
that contains:
visualvm_home=/path/to/jdk
Thanks for responding, and so fast!
Got the ~/Library/Application Support/VisualVM/2.0.6/etc/visualvm.conf alternative working. If this file had already existed, with some example configurations to "uncomment" I would have found it...
The main issue is still valid. The behaviour when picking a JVM is flawed.
I agree that the OP.
VisualVM should follow JAVA_HOME variable and only if that fails, fallback to the automatic detection.
What's more, approach with setting it via visualvm.conf is cumbersome as this file is located and read from within VisualVM.app app bundle, which is being changed during each update so each time user has to remind oneself how to fix that compat issue....
It can use the JVM that JAVA_HOME points to if that's a supported JVM. My main problem is with how the automatic detection works. Why pick a not (yet) supported JVM when there are fully supported ones available?