Community
Participate
Working Groups
from bug 125250c12 To demonstrate the overwriting of the classpath: 1. Make a Hello World RCP application via the New Project wizard. 2. Add the following lines to Application.java in the run method: // Get Properties String info = ""; info += "\nProperty Information\n"; String [] name = { "java.library.path", "java.class.path", }; for(int i=0; i < name.length; i++) { String value = System.getProperty(name[i]); String line = name[i] + ": " + value + "\n"; info += line; } System.out.print(info); 3. Make a Run configuration and put the following in the VM arguments: -cp junk1 -Djava.library.path=junk2 -Djava.class.path=junk3 I get: Property Information java.library.path: junk2 java.class.path: c:\eclipse\startup.jar It ignores the classpath. You can also try to specify the classpath in your own way. The classpath is ignored in any way I have tried. If this is not sufficient, I can send the project, but it doesn't seem necessary. The above is the only change. The problem is easy to demonstrate.
This isn't a bug. The classpath doesn't get 'overwritten'. The startup.jar launches its own VM, which has these properties set, and then it fires up a *second* VM that handle the OSGI launching. The classpath is simply not part of this process, whether specified as an environment variable or a command line parameter. The fact is that you're specifying a classpath for VM1, and expecting it to get through to VM2. You should also note that 'java.class.path' is not a settable property, so -Djava.class.path is not going to set any information. The launcher is almost certainly configured not to set the classpath in this way, and it's a misunderstanding of how the launcher VM and Eclipse VM work. As an observation, this is why when Eclipse crashes, you get a dialog box up explaining that it's crashed. VM2 goes down, VM1 notices, and displays the box. It's also how when you restart Eclipse (say, after an update manager run) Eclipse can shutdown and reopen. It returns a code to VM1 saying 'please re-launch me' and VM1 obliges. This should be closed 'not a bug'.
Thank you for your response. I don't understand VM1 and VM2. This is what I see using Dependency Walker on Windows: The program in question is JProbe SWT RCP.exe The test .ini file is JProbe SWT RCP.ini: -name Test Case -vmargs -Xms40m -Xmx256m -classpath C:\Deploy\JProbe SWT RCP JNI Test\plugins\gov.anl.xrays.epics.jca_1.0.0\jca-2.1.6.jar There are three processes: 1. Program Executable: c:\deploy\jprobe swt rcp jni test\JPROBE SWT RCP.EXE Program Arguments: Starting Directory: C:\Deploy\JProbe SWT RCP JNI Test\ 2. Program Executable: c:\windows\system32\JAVAW.EXE Program Arguments: -Xms40m -Xmx256m -classpath "C:\Deploy\JProbe SWT RCP JNI Test\plugins\gov.anl.xrays.epics.jca_1.0.0\jca-2.1.6.jar" -jar "c:\deploy\jprobe swt rcp jni test\startup.jar" -os win32 -ws win32 -arch x86 -launcher "c:\deploy\jprobe swt rcp jni test\JPROBE SWT RCP.EXE" -name "Test Case" -showsplash 600 -exitdata ffc_4c -vm C:\Windows\system32\javaw.exe -vmargs -Xms40m -Xmx256m -classpath "C:\Deploy\JProbe SWT RCP JNI Test\plugins\gov.anl.xrays.epics.jca_1.0.0\jca-2.1.6.jar" -jar "c:\deploy\jprobe swt rcp jni test\startup.jar" 3. Program Executable: c:\deploy\jprobe swt rcp jni test\JPROBE SWT RCP.EXE Program Arguments: -name "Test Case" -showsplash 600 "c:\Deploy\JProbe SWT RCP JNI Test\configuration\org.eclipse.osgi\splash.bmp" Starting Directory: C:\Deploy\JProbe SWT RCP JNI Test\ (These lines were copied from the Dependency Walker output.) Process 3. is the splash screen and would not be there if the .ini file had -nosplash. It is not part of the issue and can be ignored. Notice that the classpath from the .ini file did get passed to Javaw. Thus it *does* get overwritten (by startup.jar). I see no other virtual machine being started. It is all happening in javaw, as far as I can see. >> You should also note that 'java.class.path' is not a settable >> property, so -Djava.class.path is not going to set any information. I know that. It is irrelevant. -classpath is not. This issue was discussed in depth in Bug #125250 and a solution for the real problem was found that did not require mofifying Eclipse for that problem. The reason this Bug was started is only that it is user unfriendly to overwite something the user specifies in -vmargs. If the user specifies it, it should be included in whatever Eclipse sets for the classpath. It is the user's responsibility to do something reasonable. The issue in Bug #125250 is resolved, and this issue does not need to be continued there. I believe the purpose of this bug was to isolate this relatively small issue. Thanks again.
(In reply to comment #1) Eclipse does not start two VM's to launch. The native launcher (eclispe.exe) is native c code which is responsible for finding a VM and the startup.jar and the proceeds to run java with the -jar startup.jar. That is the one and only VM which launches eclipse. I think the problem is what the vm does when the -jar is used. We have a similar issue in bug 95733. It seems that -classpath and the environment var $CLASSPATH is ignored with -jar is used with some VMs.
yes, absolutely. if you use -jar, the -classpath or -cp stuff is ignored.
*** This bug has been marked as a duplicate of 95733 ***
I've been a bit too loose here. Reopening.
*** Bug 95733 has been marked as a duplicate of this bug. ***
Standard manifest has a basic support for expressing dependencies. It might be a way to go.
Closing as wontfix again. It is by design that we ignore the classpath variable. Eclipse does not want to expose extra stuff through the application classloader by default. This leads to a poor modularity system. If you need to do something fancy with extra classpaths then you must either launch with a different launcher jar and use pascal's suggestion in comment 8 or better yet use a real bundle that allows you to define proper modular dependencies on.
Please note that bug 95733 was marked as a dup of this one HOWEVER its complaint is exactly the opposite - the classpath is NOT ignored in all circumstances. See comment #21 in 95733: "I finally am able to reproduce this. This happens when an IBM 1.4.2 JRE is used. When using the -jar option the Sun JRE will ignore the CLASSPATH env. But the IBM 1.4.2 JRE appears to use the CLASSPATH variable even when using the -jar option."
Note that with the new launcher, bug 126499 would no longer occur when the vm is loaded using JNI invocation (since we are completely bypassing the java.exe), which it would be when starting as described in bug 126499 comment #18
OK. I submitted the bug, looks like about a year ago. I have learned to deal with it, and don't have any problem with your closing it as WONTFIX. I wrote a simple class loader that will load things from anywhere I want, though I haven't had to use it yet. One could even use the URLClassLoader to do that. The problem that initiated this bug was that JNI implementations that get callbacks from threads not started by the VM use a FindClass routine to find the Java class to handle the callback. This supplied C routine uses the standard class loader, which uses the classpath, and I have found no way to avoid that. It can be worked around as in Bug #125250 and there is a blurb in the release notes as to how to do that. Unfortunately, it involves rewriting the JNI code, which is not always possible. The problem, as with much of Eclipse, is that it is difficult to find these things out, and it uses a great deal of my time as well as that of others. In particular, I guess I need to find out about the "new launcher". The participants in this bug have been really friendly and helpful, and I appreciate that. Unfortunately, my mileage in that regard varies for other bug report. Consequently, I thank all of you for the information and feel the effort was not wasted, as others will also find the information here.
A bug needs to be opened against the IBM vm. I will look open a bug.
(In reply to comment #11) > Note that with the new launcher, bug 126499 would no longer occur when the vm > is loaded using JNI invocation (since we are completely bypassing the > java.exe), which it would be when starting as described in bug 126499 comment > #18 Andrew, I'm not following. Are you saying that this bug 126499 does not happen with the new launcher? or that the duplicated bug 95733 will no longer occur with the new launcher? This bug 126499 was opened because the classpath variable is ignored when launching with the -jar option. Is that no longer the case with the new launcher?
I think I got confused by the duplication. I meant bug 95733: with the new launcher, when using JNI invocation to start the vm, the CLASSPATH variable would not be read. (Though when we fork java in a separate process, it may be read by the java launcher). So I
