JDK-4150815 : java.io.File.getPath() does not preserve trailing separator characters
  • Type: Bug
  • Component: core-libs
  • Sub-Component: java.io
  • Affected Version: 1.2.0
  • Priority: P4
  • Status: Closed
  • Resolution: Won't Fix
  • OS: generic,solaris_2.6,windows_nt
  • CPU: generic,x86,sparc
  • Submitted: 1998-06-19
  • Updated: 1999-02-05
  • Resolved: 1999-02-05
Related Reports
Duplicate :  
JDK-4208417 - java.io.File.getAbsolutePath with null path does not return trailing slash
Relates :  
JDK-4131169 - java.io.File: Respecify using abstract pathnames rather than strings
Description
The following example program gives different results on 1.2beta4 and 1.2beta3, 1.1.6 etc.

import java.io.File;

public class GetPath {
    public static void main(String args[]) {
	File f = new File("foo" + File.separatorChar);
	System.out.println("File(\"foo" + File.separatorChar + "\")" + 
			   " getPath() = " + f.getPath());
    }
}

1.2beta4 - File("foo/") getPath() = foo
1.2beta3 - File("foo/") getPath() = foo/
1.1.6 - File("foo/") getPath() = foo/

In 1.2beta4, if a trailing File.separatorChar is used in the File constructor, it is not returned in File.getPath().  While in 1.2beta3 and 1.1.6 the trailing File.separatorChar is returned.

This is not a bug really, but could break user's code which depended on this behaviour.  SpecJava _213_javac broke with this change.  To maintain compatibility it might be a good idea to return the trailing File.separatorChar.
Comments
EVALUATION The java.io.File class was totally reworked in JDK 1.2 (see 4131169) to fix a number of longstanding problems. The root cause of many of these bugs was that the File class was originally specified in terms of string concatenation, which just doesn't fly on platforms like Win32. Unfortunately this meant introducing a small number of binary incompatibilities in certain corner-case situations. One incompatibility is that the File class no longer preserves trailing separator characters. Another is that duplicate separator characters are no longer preserved. The new File class was introduced in 1.2beta4, and in the course of testing we found that very few programs actually depended upon these behaviors. The SPECjvm suite was one of them, and the keepers of the SPECjvm code have agreed to fix it appropriately. -- mr@eng 1999/2/5
02-07-0171