visualvm icon indicating copy to clipboard operation
visualvm copied to clipboard

At startup VisualVM picks a JDK that it then decides it won't/can't run with

Open apete opened this issue 4 years ago • 4 comments

At startup VisualVM picks a JDK that it then decides it won't/can't run with.

Steps to reproduce the behavior:

  1. VisualVM 2.0.6 and macOS BigSur (Had the same problem before with other versions)
  2. Have Java 1.6, 1.8, 11, 15 and 16 installed.
  3. When starting VisualVM will choose Java 16 to run with (since it the latest...)
  4. 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

apete avatar Mar 22 '21 07:03 apete

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

thurka avatar Mar 22 '21 09:03 thurka

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.

apete avatar Mar 22 '21 09:03 apete

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....

woj-tek avatar Apr 20 '21 05:04 woj-tek

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?

apete avatar Apr 20 '21 19:04 apete