Community
Participate
Working Groups
Build Identifier: 20100617-1415, Eclipse IDE for Java Developers The behavior of "Eclipse IDE for Java Developers" and "Eclipse SDK " is different with respect to this bug. It doesn't occur in "Eclipse SDK ". "Eclipse SDK" has build ID:"I20100608-0911" - both Helios. Scenario: Multiple JREs on machine, including old versions being used with Oracle (jre 1.1.7, jre 1.4.2 - which are in 'Path' environment variable, Oracle specific subdirectories and not located in "C:\Program Files\Java\"). JRE 1.6 & jdk1.6 is installed in "C:\Program Files\Java\". "Eclipse IDE for Java Developers" seems to use Path variable to find jre and fails out without even starting up, failing out on the first found jre in Path variable. message: "Version 1.4.2_03 of the JVM is not suitable for this product. Version: 1.5 or greater is required." "Eclipse SDK" seems to be able to locate the jre within "c:\Program Files\Java\" and runs successfully. (seems to do the search for jre correctly as opposed to Eclipse for Java Dev.) Worked around the jre problem by copying the jre from within "C:\Program Files\Java\" to directory containing "Eclipse IDE for Java Developers". Both "Eclipse IDE for Java Developers" and "Eclipse SDK" were downloaded from site at same time. Paths: C:\Program Files\Eclipse\Java-3.6 == "Eclipse IDE for Java Developers" C:\Program Files\Eclipse\SDK-3.6 == "Eclipse SDK" C:\Program Files\Java\jdk1.6.0_13 == JDK - default inst. C:\Program Files\Java\jre6 == JRE - default inst. C:\oracle\product\10.1.0\Client_1\jre\1.4.2\bin == Oracle install in 'Path' C:\Program Files\Oracle\jre\1.1.7\bin == Second Oracle install in 'Path' Reproducible: Always Steps to Reproduce: See scenario mentioned in details. 1.Try to run Eclipse for Java Devs. 2. 3.
Sounds like a possible EPP problem given the data though I find that hard to believe.
Markus, do you have any clues why the behavior would differ from the SDK?
(In reply to comment #2) > Markus, do you have any clues why the behavior would differ from the SDK? In both cases it is the same launcher and after reading this bug report for the first time I couldn't believe that there is a difference between the SDK and the EPP packages. But there is a small subtle difference: The EPP packages define a minimum JRE runtime in the eclipse.ini. This parameter was introduced because many people were downloading one of the packages, started it with a JVM <1.5 and couldn't find the expected functionality because one of the bundles defined an execution environment that was not met. So I assume that the Eclipse launcher behaves in a different way if this parameter is set and fails with the first matching entry in PATH. I am forwarding this bug to the platform team, maybe they can tell more about my theory.
The native launcher finds the same JRE in all cases, which here is the first JRE on the search path. The Eclipse SDK is able to run fine on a 1.4.2 JRE. The EPP packages define "osgi.requiredJavaVersion = 1.5", this restriction is enforced in Java Main, well past the point where the launcher could choose a different vm. The native launcher currently has no knowledge of the "osgi.requiredJavaVersion" property. As well, the launcher has no good way to determine the version of the jvm before launching it.
>The native launcher finds the same JRE in all cases, which here is the first JRE >on the search path. The Eclipse SDK is able to run fine on a 1.4.2 JRE. This brings about several questions/issues/thoughts. **By default, a Java installation does not set the location of the jre in the 'Path' variable on MSFT. This allows multiple jre(s) to coexist. **Vendors of other products that may utilize a jre tend to put the jre within their dir tree and have Path point to it (Oracle - case in point). These jre(s) tend to be a bit old/outdated. **If everyone had to copy the jre into the run-time directory of an application to 'override' search path behavior that picks up some other products outdated version of a jre, the resulting multiple copies would be quite wasteful. - - It would be useful to have a 'probe' of "C:\Program Files\Java\" for a recent jre(s), since this is the default location for installation on MSFT (there is probably a corresponding location for Linux/Unix). Might be useful to have the probe before actually trying the "Path" variable which could open up the product to 'irresponsible' devs to must put their local jre in a Global env. variable. Is there a way to specify the runtime jre for eclipse itself (vs the runtime used in the dev process within eclipse)? I tried looking for this through the *.ini files and couldn't find anything or any syntax that would allow me to point to the jre in "C:\Programs Files\Java\.."
(In reply to comment #5) > Is there a way to specify the runtime jre for eclipse itself (vs the runtime > used in the dev process within eclipse)? http://wiki.eclipse.org/Eclipse.ini
The argument is -vm. See also http://wiki.eclipse.org/Equinox_Launcher. On windows, "installed" jvms are listed in the windows registry. The launcher often finds C:\Windows\System32\java.exe as the first java on the search path. In this case we consult the registry "HKLM\Software\JavaSoft\Java Runtime Environment\CurrentVersion" and use that. If CurrentVersion is not defined, we enumerate the keys to get the installed jres and we take the first one that is 1.4 or higher.
--apology in advance if this appears twice.. >On windows, "installed" jvms are listed in the windows registry. The >launcher often finds C:\Windows\System32\java.exe as the first java on the search path. >In this case we consult the registry "HKLM\Software\JavaSoft\Java >Runtime Environment\CurrentVersion" and use that. If CurrentVersion is >not defined, we enumerate the keys to get the installed jres and we >take the first one that is >1.4 or higher. Took a look at "HKLM\Software\JavaSoft\Java Runtime Environment\CurrentVersion" on machine in question. It shows 1.6 as current version and shows a path to the runtime env in "HKLM\Software\JavaSoft\Java Runtime Environment\1.6\JavaHome" to the proper location of the JRE (C:\Program Files\Java\jre6). This would not explain why it was picking up Oracles '1.4' version.
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant.
