On Linux: gcc version 3.4.0 20040131 TestD.java:12: error: unrecognized character in input stream. On Win32: gcc version 3.4.0 20040316 (prerelease) Compiles fine, but characters are either output as boxes or question marks. The test app creates two labels (A and B) The high bit ascii results when compiled: 1. All Sun's JAVA: javac -classpath swt.jar TestD.java java -classpath swt.jar;. TestD A: OK B: OK 2. Mixture of javac and GCJ. javac -classpath swt.jar TestD.java gcj -c TestD.class -I swt.jar gcj --main=TestD TestD.o libswt.a A: OK B: Wrong. Has ?'s (question marks) 3. All GCJ. gcj -c TestD.java -I swt.jar gcj --main=TestD TestD.o libswt.a A: Wrong. Has boxes. I will attach the class to this message.
Created attachment 5960 [details] Sample .java class
Created attachment 5961 [details] Screenshot of win32 results.
does --encoding=UTF-8 help?
No, it doesn't seem to make a difference. (win32 or linux)
*** Bug 13892 has been marked as a duplicate of this bug. ***
If by "high ascii" you mean byte with the high bit set, then you want to compile those with "--encoding ISO-8859-1" or the like. Whether this works on Windows, I don't know. It depends on whether iconv is available on that platform (or if you are using libiconv) What happens if you compile with "gcj -C" and then run the resulting bytecode using Sun's "java"? If this works, then the problem is not in the compiler at all but is in the runtime's choice of default character set.
It isn't a compiling problem that I'm trying to illustrate. TestD.java (included above) has a line: String s = "<high ascii chars>" characters. If these characters were received over a network connection as a byte stream, they would still be converted to a string via the "new String(byte[])" method, which is used in TestD.java. They would then be turned into a String, and displayed, as in the screenshot attached above. gcj doesn't seem to convert the characters properly (not in the same was a sun's java anyway). The testcase and screenshot hopefully communicate what I mean. Anyway, compiling to bytecode is separate issue: gcc version 4.0.0 20041213 (experimental) gcj -C --encoding=UTF-8 TestD.java TestD.java:12: error: malformed UTF-8 character. String s = "░ñâRÇÇNÇåñ░"; gcj -C --encoding=ISO-8859-1 TestD.java TestD.java:1: fatal error: unknown encoding: 'ISO-8859-1' This might mean that your locale's encoding is not supported by your system's iconv(3) implementation. If you aren't trying to use a particular encoding for your input file, try the '--encoding=UTF-8' option compilation terminated. I have mingw msys iconv (GNU libiconv 1.8) on my system.
Closing as won't fix as libgcj (and the java front-end) has been removed from the trunk.