Name: skT88420 Date: 11/12/99


java version "1.3beta"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.3beta-O)
Java(TM) HotSpot Client VM (build 1.3beta-O, mixed mode)

Run the following class (substitute baseDir as needed):

-----------%<---------------
import java.io.*;
import java.net.*;
import java.util.*;
public class URLClassLoaderTest extends Object {
  public static void main (String args[]) throws Exception {
    String baseDir = "d:\\temp";
    String subDir = "cltest";
    String fileName = "foo.txt";
    new File (baseDir + File.separator + subDir).mkdir ();
    new File (baseDir + File.separator + subDir + File.separator +
fileName).createNewFile ();
    URL url1 = new File (baseDir + File.separator + subDir).toURL ();
    ClassLoader cl1 = new URLClassLoader (new URL[] { url1 });
    System.out.println ("Find: " + url1 + " -> " + cl1.getResource (fileName));
    URL url2 = new File (baseDir + File.separator + "." + File.separator +
subDir).toURL ();
    ClassLoader cl2 = new URLClassLoader (new URL[] { url2 });
    System.out.println ("Find: " + url2 + " -> " + cl2.getResource (fileName));
    URLConnection conn1 = new URL (url1, fileName).openConnection ();
    System.out.println ("conn1.url=" + conn1.getURL ());
    URLConnection conn2 = new URL (url2, fileName).openConnection ();
    System.out.println ("conn2.url=" + conn2.getURL ());
  }
}
-----------%<---------------

Output is as follows:

-----------%<---------------
Find: file:/d:/temp/cltest/ -> file:/d:/temp/cltest/foo.txt
Find: file:/d:/temp/./cltest/ -> null
conn1.url=file:/d:/temp/cltest/foo.txt
conn2.url=file:/d:/temp/cltest/foo.txt
-----------%<---------------

Checked on NT 4.0 with both 1.2.2 and 1.3b. Did not check on Unix, though
I suspect the problem would also occur there.

The problem: often file names are given with a dot in them. For example, if
the current directory is used as a base for File objects, often
there will be a ./ sequence in the file path. Using File objects this normally
makes no difference, /./ is treated exactly like /. And when the URL is created
using toURL(), it appears that this /./ is preserved, though as above this does
not seem to affect opening a basic URLConnection. However, the URLClassLoader
when created with such a URL will fail to find anything whatsoever. This seems
inconsistent and it is certainly not obvious why the classloader fails to work
unless you examine the URLs and happen to notice the /./.
(Review ID: 97765)
======================================================================