> > BUG 1 - Project.translatePath() > > > > 1. org.apache.tools.ant.taskdefs.Javac uses Project.translatePath() to > > convert various paths to native format (i.e., Unix to Win32, etc.). But > > Project.translatePath() does not always correctly handle Win32 paths with > > forward slashes, converting for example > > > > d:/jdk1.3/jre/lib/ext > > > > to > > > > d;\jdk1.3\jre\lib\ext > > > > But paths with forward slashes and a drive letter are not strictly Win32 > paths.
Apache and Tomcat recognize and handle c:/path/path/file correctly. So does Perl, most editors, most zip tools, all the java.io.* classes and all the GNU utilities. Principle of least astonishment. Converting c:/path to c;\path is a bug. Code should be robust enough to handle it. > If you are going to have an absolute Win32 path, why not just use > backslashes (the win32 convention). The code there today > (Project.translatePath()) currently handles C:\blah\blah or even > c:\blah/blah without any problems. I would think requiring paths to be written one way for Win32 and another for Unix defeats the purpose of Project.translatePath(). The goal should be that a build.xml file should be able to be lifted from one environment and used in another with as little difficulty as possible. The heuristic I propose leaves c:\blah\blah and c:\blah/blah untouched in a Win32 environment > Your heuristic will decide that all single letter paths are Win32 paths > which may not be a good choice. Your approach to converting an absolute > Win32 path to a Unix path will rarely result in a useful path. True. The current translatePath() doesn't produce a usable Unix path from "c:\path\path\file" either. Absolute paths don't map correctly in either direction, but this is an inherent problem with the two architectures. My reasoning for the proposed fix is that virtually all Win32 tools (with the exception of cmd.exe) allow for either forward slashes or backslashes. In many contexts backslashes within a string are used to escape the next character, but never forward slashes. If a tool recognizes c:\path\file and c:\path/file correctly, it is reasonable for the programmer to expect that it will also handle c:/path/file, and not convert it to c;\path\file. Thanks, Phil Hanna
