Bug 10005 - InternalBootLoader will not work when directory name contains a space
Summary: InternalBootLoader will not work when directory name contains a space
Status: RESOLVED DUPLICATE of bug 3106
Alias: None
Product: Platform
Classification: Eclipse Project
Component: Resources (show other bugs)
Version: 2.0   Edit
Hardware: PC Windows 2000
: P2 normal (vote)
Target Milestone: ---   Edit
Assignee: DJ Houghton CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2002-02-19 13:45 EST by Tim Francis CLA
Modified: 2002-04-05 18:00 EST (History)
0 users

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Tim Francis CLA 2002-02-19 13:45:44 EST
The InternalBootLoader.initialize() method assumes it can get a valid
filename from the install URL, by calling getFile() on the URL.  This does
not work if the URL (aka, install location) contains a character that needs
escaping in a URL - such as a space.  Older JDKs would return a space, 
but newer JDKs (such as 1.4, and some recent 1.3 refreshes) return a String  
like 
 installURL.getFile()=/C:/program%20files/eclipse/
This is a valid URL, but it cannot be used to construct a File object
(which is what the initialize method does).  The result is that when 
the workbench is installed in a directory with a space (like "Program Files") 
it will not wok with the newer JDKs.

This is the subject of sunbug 4466485 (see 
http://developer.java.sun.com/developer/bugParade/bugs/4466485.html ), but that 
bug has been closed as working-as-designed, so it appears unlikely to change.

The workaround proposed by sun is to use the URI.getPath() - but java.net.URI 
was only introduced in JDK 1.4, so that will not run on 1.3.  There are a 
couple of places in the InternalBootLoader.initialize() method to fix up (and 
anywhere else in the code that calls "new File(URL.getFile())".  

The easiest way to reproduce the problem is to download the 1.4 JDK, but I have 
had this reported on 1.3 as well, so we do need to address it now.

Finally, here's a quick standalone testcase to show the problem - if you move 
the class file from this source into a directory with a space and you have a 
recent JDK) you'll see the problem.

import java.net.*;
import java.io.*;

public class SpaceTest
{
   public static void main(String[] args)
   {
      try
      {
         SpaceTest instance=new SpaceTest();
         URL url=instance.getClass().getProtectionDomain().getCodeSource
().getLocation();
         System.out.println("URL="+url.toString());
         System.out.println("URL.getFile()="+url.getFile());

         File file=new File(url.getFile());
         System.out.println("file="+file.toString());
         System.out.println("file.getPath()="+file.getPath());
         System.out.println("file.exists()="+file.exists());

         // Proposed fix from sun, only works on JDK 1.4
         File urifile=new File(new URI(url.toString()).getPath());
         System.out.println("urifile.getPath()="+urifile.getPath());
         System.out.println("urifile.exists()="+urifile.exists());
      }
      catch(Exception x)
      {
         x.printStackTrace();
      }
   }
}

Output from this testcase:

URL=file:/C:/tmp/with%20space/
URL.getFile()=/C:/tmp/with%20space/
file=C:\tmp\with%20space
file.getPath()=C:\tmp\with%20space
file.exists()=false
urifile.getPath()=C:\tmp\with space
urifile.exists()=true
Comment 1 DJ Houghton CLA 2002-04-05 18:00:15 EST

*** This bug has been marked as a duplicate of 3106 ***