Community
Participate
Working Groups
- Fresh workspace - Add 1.4.2 IBM JRE to your workspace (I also have 1.5 and 1.6 JREs added to the workspace) - Java > Installed JREs > Execution environments > J2SE 1.4 => 1.4.2. JRE is not shown as a compatible match - Import projects which use 1.4 as an execution environment e.g. o.e.pde.ui => The JRE container will show 1.6 JRE This is a major bug as I cannot build against 1.4 JRE. Note: - Things work with 3.8 M4 - Things also work with new builds and older workspaces (Things are fine in my dev workspace). The problem surfaces only in new workspaces.
I should also add that the problem is reproducible on 2 Windows machines and 1 Linux machine. => Problem cannot be because of corrupted JRE or some other system issue.
I tried to check out jdt.core sources into the new build, but they won't compile anymore because there's no 1.4 JRE attached to the 1.4 EE
When I try to add a former Sun JDK I even get an error dialog: "Could not find the main class. Program will exit. plus .log entry: !ENTRY org.eclipse.jdt.launching 4 4 2012-01-24 10:36:17.544 !MESSAGE Failed to retrieve default libraries for C:\JavaSDKs\jdk1.4.2_16 For the IBM JDK I get only a .log entry (no error dialog): ENTRY org.eclipse.jdt.launching 4 4 2012-01-24 10:36:54.878 !MESSAGE Unable to retrieve system properties !STACK 1 org.eclipse.core.runtime.CoreException: Unable to retrieve system properties at org.eclipse.jdt.launching.AbstractVMInstall.abort(AbstractVMInstall.java:500) at org.eclipse.jdt.launching.AbstractVMInstall.evaluateSystemProperties(AbstractVMInstall.java:450) at org.eclipse.jdt.internal.launching.environments.ExecutionEnvironmentAnalyzer.isFoundation1_0(ExecutionEnvironmentAnalyzer.java:142) at org.eclipse.jdt.internal.launching.environments.ExecutionEnvironmentAnalyzer.analyze(ExecutionEnvironmentAnalyzer.java:90) at org.eclipse.jdt.internal.launching.environments.Analyzer.analyze(Analyzer.java:40) at org.eclipse.jdt.internal.launching.environments.EnvironmentsManager.analyze(EnvironmentsManager.java:337) at org.eclipse.jdt.internal.launching.environments.EnvironmentsManager.vmAdded(EnvironmentsManager.java:376) at org.eclipse.jdt.launching.JavaRuntime.fireVMAdded(JavaRuntime.java:2353) at org.eclipse.jdt.launching.VMStandin.convertToRealVM(VMStandin.java:151) at org.eclipse.jdt.internal.launching.LaunchingPlugin.processVMPrefsChanged(LaunchingPlugin.java:685) at org.eclipse.jdt.internal.launching.LaunchingPlugin.preferenceChange(LaunchingPlugin.java:1244) at org.eclipse.core.internal.preferences.EclipsePreferences$3.run(EclipsePreferences.java:864) at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42) at org.eclipse.core.internal.preferences.EclipsePreferences.firePreferenceEvent(EclipsePreferences.java:867) at org.eclipse.core.internal.preferences.EclipsePreferences.put(EclipsePreferences.java:880) at org.eclipse.jdt.internal.debug.ui.jres.JREsUpdater$1.run(JREsUpdater.java:91) at org.eclipse.jface.operation.ModalContext$ModalContextThread.run(ModalContext.java:121) !SUBENTRY 1 org.eclipse.jdt.launching 4 150 2012-01-24 10:36:54.879 !MESSAGE Unable to retrieve system properties
The launchingsupport.jar must be compiled against 1.4 otherwise the JRE detection fails. Here's the command that gets executed: [C:\JavaSDKs\jdk1.4.2_30\bin\javaw.exe, -classpath, C:\eclipse\workspaces\HEAD\Git\eclipse.jdt.debug\org.eclipse.jdt.launching\lib\launchingsupport.jar, org.eclipse.jdt.internal.launching.support.LibraryDetector]
Fixed in master: c4c8b2bcda2c85f80ba158588c18b0f21e4cbe0b
I'm not sure if the jsr14 target is a good idea. This still excludes 1.1 to 1.3 JREs. We should better revert buildLaunchingSupportJAR.xml and the "support" source folder to the 3.7 state and accept the raw type problem (set it to warning in Eclipse).
(In reply to comment #6) > I'm not sure if the jsr14 target is a good idea. This still excludes 1.1 to 1.3 > JREs. I was thinking the same.
(In reply to comment #7) > (In reply to comment #6) > > I'm not sure if the jsr14 target is a good idea. This still excludes 1.1 to 1.3 > > JREs. > I was thinking the same. Yes, I agree that's better. Fixed in master: 326c18fbedc10203bac95c6399a022b8ea04e1a0
Tested with a 1.4, 1.3, 1.2 and a 1.1 JRE.
*** Bug 369577 has been marked as a duplicate of this bug. ***
I have org.eclipse.jdt.launching 3.6.100.v20120124-1313 from last night's build, but I have the same problem. Loading the 1.4.2 JRE finds the jre/lib/ext jars, but not the jre/lib jars, and won't show up under the J2SE-1.4 EE preference PW
(In reply to comment #11) > I have org.eclipse.jdt.launching 3.6.100.v20120124-1313 from last night's > build, but I have the same problem. > > Loading the 1.4.2 JRE finds the jre/lib/ext jars, but not the jre/lib jars, and > won't show up under the J2SE-1.4 EE preference > > PW Same here. Something is fishy. I verified that the source is OK and that the right source files are tagged in Git. There seems to be some missing piece when the builder actually builds the JAR. From the manifest it looks like 1.6 was used.
OMG! The official build never built the support JAR using the Ant script. Instead it uses the normal build and EE specified by the bundle. Hence the resulting class file version so far was 1.2 and now it's 1.5. Working on a fix...
Fixed in master: 60db1080d6e3e6a07ccf22bdf9848e7e4e1aff2d To ensure that what a developer tests from his workspace also works in the official build, we no longer build the JAR during the official build, but instead check in the JAR which gets built in the workspace using the Ant script. This is the same approach we already take to build the antsupportlib.jar. Another more difficult fix would have been to change the entire project to custom build.
> Another more difficult fix would have been to change the entire project to > custom build. There's a third way via customBuildCallbacks.xml, see http://help.eclipse.org/indigo/index.jsp?topic=/org.eclipse.pde.doc.user/tasks/pde_custom_callbacks.htm But that's too dangerous to try for 3.8 M5. In bug 324794, we partially implemented this, but we still left the pre-compiled JAR in the repository.
Finally! Verified in I20120125-1300.
