#144 [367] Don't compile files in directories with special chars

[Andriy G. Tereshchenko]

[367]
From philip@heede.org Sun Nov 12 14:40:13 2000
Received: from localhost (IDENT:nobody@localhost [127.0.0.1])
by oss.software.ibm.com (8.9.3/8.9.3) with ESMTP id OAA15539
for <jikes-bugs@oss.software.ibm.com>; Sun, 12 Nov 2000 14:40:08 -0500
Date: Sun, 12 Nov 2000 14:40:08 -0500
From: philip@heede.org
Message-Id: <200011121940.OAA15539@oss.software.ibm.com>
To: jikes-bugs@oss.software.ibm.com
Subject: Fails to compile files in directories with names containing special characters

Full_Name: Philip Heede
Version: 1.12
OS: Windows 2000
Submission from: (NULL) (195.212.29.33)

Jikes v1.12 running on Windows 2000 fails to compile .java files in residing in
directories with a name that contains special characters, specifically in my
case, Danish national characters (§čĄă§ç¨b¨nŠŕ):

With a file called Set.java residing in the directory "d:\special directory
§čĄă§ç\":
D:\special directory §čĄă§ç> jikes Set.java

Issued 1 System warning:

*** Caution: The input file "Set.java" was not found.

Thanks for any help you can provide!
Philip

[Nobody/Anonymous]

I have also had such a problem with Jikes:

Failed to compile: '/tmp/10371/foo\ahoj/$th (e) re/lala/Testme.java'
(Contents of the file irrelevant; package lala.)
Both FastJavac and Javac compiled the file correctly.
Jikes complained that the file could not be found.
Filenames and classpath were correctly quoted before passing to Jikes:
-------%<-------
#!/bin/bash
"$@"
echo -n 'Running:' 1>&2
while [ $# -gt 0 ]
do
echo -n " '$1'" 1>&2
shift
done
-------%<-------

This is on Linux with Jikes 1.12 RPM install.

[Nobody/Anonymous]

Same issue on Win2K when directory contains diacritic characters (...) that are displayed as escaped unicode values.
becomes \jFFE9 and then directory cannot be opened.

[javac] *** Caution: The input file D:/Development/gamel_M\uFFE9taMarch\uFFE9_Client_v1.0/AMM_Services/src/com/financetechnologie/core/service/ServiceManager.java" was not found.

[Nobody/Anonymous]

There is the same problem with special characters in filenames.
OS: Windows 2000
Version: 1.15, 1.16

Source:
---8<---8<---
public class JikesBogu\u00E9 {
public static void main(String[] args) {
System.out.println("Jikes 1.16 et ant\u00E9rieurs sont bogu\u00E9s !");
}
}
---8<---8<---
Save the source as "JikesBogu.java" (note the 'e' acute before the dot).

---8<---8<---
C:\&gt;jikes *.java

Issued 1 system warning:

*** Caution: The input file "JikesBogu\uFFE9.java" was not found.

C:\&gt;
---8<---8<---

The problem seems that non-ASCII characters are tranlated to Java notation, at least in the error message.

Dolmen

[Nobody/Anonymous]

Please also notes that '\uFFE9' is not the escaped unicode value of ''.
The right code code is '\u00E9'.

[Nobody/Anonymous]

This specific issue has been solved only partly in the Sn JDK as well. The problem relates to some unspecified behavior when mapping a native file path to a URI and back to a file path.
For now Java 1.4.1 is making a fully conforming conversion from a natie file path to an URI, but not in the reverse direction (where Sun's implementation incorrectly manage URL-encoded %XX characters first into the UTF-8 internal encoding, then back to the native encoding used by the hosting platform)
Jikes is worse than Javac for that issue, as it simply does not make a clear distinction between a URI, an intermediate internal UTF-8 serialization, the effective UTF-16 String internal encoding of individual path elements for Unicode conformance, and an external encoding for the native OS.
All this should be fixed in the sun.io.File package, within its internal JNI interfaces and native OS support binary implementations in the standard library.

Then Jikes could then mimic this behavior when managing files internally with URI instead of the external ASCII compatible representation used by Java for external resources. On Windows, this requires using the OS support for conversion between the native localized ANSI encoding and the locale-neutral Unicode internal encoding. On Unix/Linux, this requires supporting correctly the iconv libraries, according to the system locale or the locale used in the user console.