Community
Participate
Working Groups
If the IJavaRuntime instance wishes to use the default workspace JRE, it can return null from its getVMInstall(). And in this case, the RuntimeBridge sets up the JRE container property properly for indicating use of the default JRE. However, the logic for determining the VM version does not support this case (using the default JRE). The current vm version logic treats the returned null from getVMInstall() as an unknown JVM and logs a "Could not determine VM version for: Unknown" warning messages (actually many such messages are logged since this is called numerous times). Since we have tools that define runtimes that can specify use of the default workspace JRE, these multiple warnings in the log occur and can be a RAS issue. Instead of this, the logic could call JavaRuntime.getDefaultVMInstall() to get the default workspace JRE for calculating the version. The current logic for version calculation is: if (vmInstall == null) vmInstall = javaRuntime.getVMInstall(); if (jvmver == null) { IVMInstall2 vmInstall2 = (IVMInstall2) vmInstall; vmInstall2 = (IVMInstall2) vmInstall; if (vmInstall2 != null) jvmver = vmInstall2.getJavaVersion(); } This can be updated as follows to handle the default JRE's version: if (vmInstall == null) vmInstall = javaRuntime.getVMInstall(); if (jvmver == null) { IVMInstall2 vmInstall2; if (vmInstall != null) vmInstall2 = (IVMInstall2) vmInstall; else vmInstall2 = (IVMInstall2) JavaRuntime.getDefaultVMInstall(); if (vmInstall2 != null) jvmver = vmInstall2.getJavaVersion(); }
If you take a look at HEAD (was making similar changes due to the classpath being incorrect for the default VM), you'll see that several of the other server types have a secondary method isUsingDefaultJRE() that was missed on the IJavaRuntime interface. The original plan was that this method would be used instead and IJavaRuntime would always return a valid VM. I can't add the method to IJavaRuntime now due to WTP's adopters usage of this interface, so I added a hack to the bridge to use reflection to look for this method. At this point I am leaning towards closing this bug and asking you to implement isUsingDefaultJRE() instead. Allowing null return values from getVMInstall() doesn't allow for the case where the runtime doesn't actually have a VM at all. I'll hold onto this for a couple days to allow you to check the code I'm talking about and for me to consider.
I've looked at this again, and I stand by my original comments. Making this change wouldn't allow the runtime bridge to know the difference between a runtime that specifically wants to use the default JRE, and one that just happens to be pointing to that JRE. It also would mess up the case where a runtime is missing its JRE. For now, you should always return a JRE from your getVMInstall() method and add an isUsingDefaultJRE() method. For WTP 2.0, we should add isUsingDefaultJRE() to the IJavaRuntime interface so that it is standard for all Java runtimes. I'll change the summary and status of this bug to track the WTP 2.0 change.
Fix dropped to HEAD, will be released shortly.
Released to 2.0.
Closing as fixed since M3. If this was closed in error, please reopen.
