Community
Participate
Working Groups
I'm trying to set up a public version of Eclipse that everyone on our network can run without installing anything. So I installed it on my XP machine (works fine) then copied the entire Eclipse directory to a network location. The path name for the executable is something like \\machinename\tools\Eclipse\bin\Eclipse.exe . When I try to invoke this (from a Command window with the UNC path, or by adding it to my PATH and running 'Eclipse.exe', or by looking at the directory in the Windows explorer and double clicking Eclipse.exe), I get an error dialog that says: 'Problems during startup. Check the ".log" file in the ".metadata" directory of your workspace.' That file contains these lines: !SESSION ---------------------------------------------------------------------- !ENTRY org.eclipse.core.launcher 4 0 Dec 18, 2002 22:13:33.991 !MESSAGE Exception launching the Eclipse Platform: !STACK java.lang.RuntimeException: Could not find bootstrap code. Check location of boot plug-in or specify -boot. at org.eclipse.core.launcher.Main.searchForBoot(Main.java:424) at org.eclipse.core.launcher.Main.getBootPath(Main.java:394) at org.eclipse.core.launcher.Main.basicRun(Main.java:237) at org.eclipse.core.launcher.Main.run(Main.java:703) at org.eclipse.core.launcher.Main.main(Main.java:539) I tried some variants of the -boot and -configuration options but couldn't get it to work. For various reasons I can't ask my users to map a network drive to this location but if I do that as a test, for example I map drive letter Z: to \\machinename\tools and run 'z:\Eclipse\bin\eclipse.exe' then it works just fine. So it looks like a problem with the system using a UNC pathname.
*** Bug 33265 has been marked as a duplicate of this bug. ***
Do we know why this is happening yet? If it's a limitation of the Java VM, then there's not much we can do. If it's a just a bug in our code, then we should find it and fix it. UNC is part of the platform, and we should support it.
Should try the new runtime on UNC paths to confirm that our URL handling is correct.
Assigning to Jeff since he is the last one who commented it :-)
I spent about a day going over the code in Main and the lower levels of OSGi to find everywhere that we are manipulating paths/URLs. The basic rule is: if it is (or you want) a file: URL then to do any manipulation you have to make a java.io.File and use .toURL(). This does the right thing withrespect to /. This is true for both UNC paths as well as normal paths. There is some dispute about the normal case since File.toURL() will insert a / before the c:. This is totally legal and actually the most correct answer. People are bummed however because that means that URL.getFile() returns sometihng like /c:/foo. The File constructors handle this just fine so it is really only an issue if you are comparing URLs or showing them to users. In either case you should be normalizing the URLs before comparison. In the case of a file: URL, the normalization process is to convert to File first and then compare. File comparison handles the / diffs as well as the appropriate case handling. Anyway, I have done rudimentary testing for all combinations of Eclipse installed on a UNC path/normal path and the workspace on a UNC path/normal path. There may well be bugs in other parts of Eclipse which may do URL manipulation. If so, bugs should be opened in those components.
