Name: nt126004 Date: 05/19/2003


FULL PRODUCT VERSION :
java version "1.4.1_02"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.1_02-b06)
Java HotSpot(TM) Client VM (build 1.4.1_02-b06, mixed mode)


FULL OS VERSION :
Microsoft Windows 2000 [Version 5.00.2195]

A DESCRIPTION OF THE PROBLEM :
When a URI is created by resolving a relative URI against one created from a java.io.File, calling getSchemeSpecificPart on the new URI will return a string with the illegal characters escaped. This conflicts with the documentation for
getSchemeSpecificPart, which states "The string returned by this method is equal to that returned by the getRawSchemeSpecificPart method except that all sequences of escaped octets are decoded."

It seems the problem is that URI.resolve(URI) escapes the passed URI.
This causes the relative URI to be doubly escaped. The behavior is not
documented in the javadoc.

This bug does not interfere with converting the resulting URI into a File (via new File(URI)).

Calling getPath on the new URI returns a decoded string, as expected. However, this is not a good workaround, as it will break code that deals with URIs generically (if ever it encounters a URI with an authority or query section).

FWIW, the problem also occurs with JDK 1.4.1_01 on Mac OS X.

STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
Please compile and execute the provided test case. It creates three URIs:

(1) A relative URI containing spaces created using new URI(String). The argument String is escaped. (It is not shown here, but I also tried using URI(null, String, null) with an unescaped String. The results were the same.)

(2) A file URI created from File representing a file path with spaces in it.

(3) A new URI created by resolving (1) against (2).

...and prints their contents to standard out.

EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
[On System.out]

1: Relative%20with%20spaces
  scheme: null
  ssp: Relative with spaces
     auth: null
     path: Relative with spaces
     query: null
  frag: null
2: file:/F:/tmp/dir%20with%20spaces/File%20with%20spaces
  scheme: file
  ssp: /F:/tmp/dir with spaces/File with spaces
     auth: null
     path: /F:/tmp/dir with spaces/File with spaces
     query: null
  frag: null
3: file:/F:/tmp/dir%20with%20spaces/Relative%20with%20spaces
  scheme: file
  ssp: /F:/tmp/dir with spaces/Relative with spaces
     auth: null
     path: /F:/tmp/dir with spaces/Relative with spaces
     query: null
  frag: null

ACTUAL -
[1 & 2 are as expected. Snipped for clarity.]

3: file:/F:/tmp/dir%20with%20spaces/Relative%20with%20spaces
  scheme: file
  ssp: /F:/tmp/dir%20with%20spaces/Relative%20with%20spaces
     auth: null
     path: /F:/tmp/dir with spaces/Relative with spaces
     query: null
  frag: null

Please note the difference in ssp for URI 3.

REPRODUCIBILITY :
This bug can be reproduced always.

---------- BEGIN SOURCE ----------
import java.io.File;
import java.net.URI;

public class FileURITest {

    public static void main(String[] args) throws Exception {
        URI one = new URI("Relative%20with%20spaces");
        URI two = (new File("/tmp/dir with spaces/File with spaces")).toURI();
        URI three = two.resolve(one);
        URI four = new URI("http://foobar.com/");
        URI five = four.resolve(one);
        
        printURI("1", one);
        printURI("2", two);
        printURI("3", three);
        printURI("4", four);
        printURI("5", five);
    }
    
    private static void printURI(String label, URI uri) {
        System.out.println(label + ": " + uri);
        System.out.println(" scheme: " + uri.getScheme());
        System.out.println(" raw: " + uri.getRawSchemeSpecificPart());
        System.out.println(" ssp: " + uri.getSchemeSpecificPart());
        System.out.println(" auth: " + uri.getAuthority());
        System.out.println(" path: " + uri.getPath());
        System.out.println(" query: " + uri.getQuery());
        System.out.println(" frag: " + uri.getFragment());
    }
}
---------- END SOURCE ----------

CUSTOMER SUBMITTED WORKAROUND :
URLDecoder.decode(uri.getSchemeSpecificPart(), "UTF-8") seems to work.
(Review ID: 185954)
======================================================================