Community
Participate
Working Groups
Build Identifier: 3.7.1 JavaRuntime computeVMInstall(ILaunchConfiguration) method returns the very first VM from {workspace}\.metadata\.plugins\org.eclipse.core.runtime\.settings\org.eclipse.jdt.launching.prefs instead of the workspace default VM if no compatible VM version is found for the given launch configuration. This may not seem a serious issue but it creates a lot of confusion to the user. This behaviour was noticed/discovered while using the maven m2e eclipse plugin. IMHO JavaRuntime computeVMInstall(ILaunchConfiguration) should return the workspace default JVM and not the first VM from the preference file. The JREContainerInitializer: public static IVMInstall resolveVM(IExecutionEnvironment environment) method should be modified so that it returns the default workspace VM. public static IVMInstall resolveVM(IExecutionEnvironment environment) { if (JREContainer.DEBUG_JRE_CONTAINER) { System.out.println("<JRE_CONTAINER> resolveVM(IExecutionEnvironment)"); //$NON-NLS-1$ } IVMInstall vm = environment.getDefaultVM(); if (vm == null) { IVMInstall[] installs = environment.getCompatibleVMs(); // take the first strictly compatible vm if there is no default if (installs.length == 0 && JREContainer.DEBUG_JRE_CONTAINER) { System.out.println("\t*** NO COMPATIBLE VMS ***"); //$NON-NLS-1$ } for (int i = 0; i < installs.length; i++) { IVMInstall install = installs[i]; if (environment.isStrictlyCompatible(install)) { vm = install; if (installs.length == 0 && JREContainer.DEBUG_JRE_CONTAINER) { System.out.println("\tPerfect Match: " + vm.getName()); //$NON-NLS-1$ } break; } } // use the first vm failing that if (vm == null && installs.length > 0) { vm= JavaRuntime.getDefaultVMInstall(); if (installs.length == 0 && JREContainer.DEBUG_JRE_CONTAINER) { System.out.println("\tFirst Match: " + vm.getName()); //$NON-NLS-1$ } } } else { if (JREContainer.DEBUG_JRE_CONTAINER) { System.out.println("\tUser Default VM: " + vm.getName()); //$NON-NLS-1$ } } return vm; } Reproducible: Always Steps to Reproduce: The below instructions are just an example how this behaviour causes confusion with maven. This behaviour has nothing to do with m2e plugin itself! 1. I had two JVM's installed JRE 7 and JDK 1.6. 2. Eclipse starts up and discovers JRE 7 and automatically adds it as the default JRE for the workspace. 3. I then add the JDK 1.6 VM from the preferences and made it the workspace default VM. 4. I create a project using m2e plugin and the execution environment for the project is set to J2SE 1.5. 5.When I compile the project using maven install for the first time. It works. 6.Now I run maven clean 7.Now if you try to run maven install. Maven complains that JDK is not installed. The user has already added a JDK VM in the preferences and has set it as the workspace default and it creates a lot of confusion.
Created attachment 210880 [details] simple patch to change JREContainerInitializer
Moving to JDT/Debug
(In reply to comment #0) > Steps to Reproduce: > The below instructions are just an example how this behaviour causes confusion > with maven. This behaviour has nothing to do with m2e plugin itself! > > 1. I had two JVM's installed JRE 7 and JDK 1.6. > 2. Eclipse starts up and discovers JRE 7 and automatically adds it as the > default JRE for the workspace. > 3. I then add the JDK 1.6 VM from the preferences and made it the workspace > default VM. > > 4. I create a project using m2e plugin and the execution environment for the > project is set to J2SE 1.5. So at this point you have installed JREs and everything is fine. > 5.When I compile the project using maven install for the first time. It works. > 6.Now I run maven clean But after whatever Maven clean does you now have no installed JREs or the Maven tooling is failing to find them. If you check your JRE preferences are they all still installed (on the workspace preference page)? > 7.Now if you try to run maven install. Maven complains that JDK is not > installed. > The user has already added a JDK VM in the preferences and has set it as the > workspace default and it creates a lot of confusion. I am going to pass this over to the m2e guys to see what they have to say (since I have no idea how their tooling works)
As I wrote in the description maven is just an example here. There is nothing maven specific here. The only reason why I used maven example is because maven fails to compile with a VM created from a JRE. Why it works the first time, frankly I did not investigate that. I will describe you a scenario without maven. 1. I have a system with JDK 6 and JRE 7. 2. Start up eclipse 3. Go to preferences ->installed JRE ;and you will notice that JRE 7 is already there, perhaps JNI adds the most recent version. 4. Add JDK 6 to the installed JREs and make it the workspace default but do not remove JRE 7. 5. create a new java project that uses execution env. J2SE5. 6. Run this project from eclipse. Notice in the console JRE 7 is used to run this project and not JDK 6; although JDK 6 is the workspace default.
@Michael judging by comment #4 the issue is not specific to m2e. @Samrat you can select JRE in Maven Launch configuration JRE tab
(In reply to comment #5) > @Michael judging by comment #4 the issue is not specific to m2e. > I agree. Samrat, you should have used the example from comment 4 at the start :) Moving back to debug.
(In reply to comment #6) > (In reply to comment #5) > > @Michael judging by comment #4 the issue is not specific to m2e. > > > > I agree. Samrat, you should have used the example from comment 4 at the start > :) > > Moving back to debug. Michael, it doesn't seem a very noticeable thing in such a small example :) but nevertheless in the original description I did mention that this is not a maven specific thing :). Cheers Samrat
pushed the patch + minor update to master: http://git.eclipse.org/c/jdt/eclipse.jdt.debug.git/commit/?id=919e71f91e5624d95d0c135fdb24658caa756d70 I retained the old logic in the case the default VM install is null. Thanks for the patch Samrat!
> Notice in the console JRE 7 is used to run this project and not JDK 6; > although JDK 6 is the workspace default. Ok, so you want the workspace default vm to be used IF it is compatible to the Execution Environment. But there are cases where the workspace default vm is NOT compatible to the Execution Environment!
Sorry guys, but this issue is not fixed correctly at the moment. You can only use the workspace default vm if it is part of the list of compatible vms for the examined execution environment! In the moment the code is like this: 1. Take the first perfect match. 2. If no perfect match, use workspace default vm. 3. If no workspace default vm, use first compatible vm from list. But what if the workspace default vm is NOT compatible with the exe env? Step 2 is wrong, because you cannot use the workspace default vm unconditionally. You can only use the workspace default vm if it is compatible to the EE! The code must look like this: if( vm == null && installs.length > 0 && Arrays.asList(env.getCompatibleVMs()).contains(JavaRuntime.getDefaultVMInstall())) { vm = JavaRuntime.getDefaultVMInstall(); }
Created attachment 258533 [details] Patch to only use the workspace default vm when it is compatible to the EE. I added a patch that shows you how the code should look. Would be nice if this is fixed in Eclipse 4.5.2 release. I stumbled over these lines of code because I am working for a company that offers a real-time capable VM named JamaicaVM. We have an Eclipse plug-in so users can add our VM to Eclipse. I have a screenshot that shows you the effects.
Created attachment 258534 [details] Added screenshot showing Execution Environments mapped to incomaptible VM. EE 'JamaicaVM-6' and 'JavaSE-1.8' are mapped to incompatible VMs because workspace default VM is used even when it is not compatible to EE.
Jens, From the screenshot, I am not sure how Java 1.8 can be mapped to 1.7? We can select only from the compatible list of JREs which is provided in the table ?
Created attachment 258537 [details] Screenshot showing installed JREs.
Created attachment 258538 [details] Screenshot showing Exe Env list.
(In reply to Sarika Sinha from comment #13) > Jens, > From the screenshot, I am not sure how Java 1.8 can be mapped to 1.7? We can > select only from the compatible list of JREs which is provided in the table ? Hi Sarika, I added two more screenshots to explain the situation. One shows my Installed JREs and the second shows the list of compatible VMs for EE 'JavaSE-1.8'. There is no perfect match for 'JavaSE-1.8' Exe Env, that's why he uses the workspace default VM, which is JDK 1.7! I hope you can see that this is a wrong behaviour! :) Kind Regards, Jens
Hi Jens, Thanks for attaching the screenshots, So let me understand this. In the screenshot, For Java SE 1.8, there is no perfect match but there is a compatible VM but it still uses the default VM 1.7. I hope I have stated the problem correctly. If my understanding is correct, Please create a new bug so that I can work on it. Thanks.
(In reply to Sarika Sinha from comment #17) > Hi Jens, > Thanks for attaching the screenshots, So let me understand this. In the > screenshot, For Java SE 1.8, there is no perfect match but there is a > compatible VM but it still uses the default VM 1.7. I hope I have stated the > problem correctly. > > If my understanding is correct, Please create a new bug so that I can work > on it. > > Thanks. Hi Sarika, in the moment, when there is no perfect match for an Exe Env, he just unconditionally takes the workspace default VM, even when that is NOT compatible with the passed Exe Env. That's the bug. I will open a new bug entry as you requested. Thanks for your help. Regards, Jens
(In reply to Sarika Sinha from comment #17) > If my understanding is correct, Please create a new bug so that I can work on it. Sarika, I created this bug entry for the issue: https://bugs.eclipse.org/bugs/show_bug.cgi?id=484026
Thanks Jens
