IBMJava2-ppc-142: little surprises
Joseph E. Sacco, Ph.D.
joseph_sacco at comcast.net
Tue Jan 11 09:59:39 MST 2005
I uncovered the source of the java compilation problem I encountered
while building the kde java bindings for kde-3.3.2.
The konstruct build of the kde java bindings involves a step where 723
source files are simultaneously fed to the java compiler. The
compilation process fails, issuing the complaint:
error: IO exception sun.io.MalformedInputException
In order to identify the culprit(s), I wrote a simple "for loop" that
compiled the 723 java source files one at a time and captured any output
to a text file. I found one java source file that failed to compile,
KListView.java, inflicted collateral damage on several others. I stared
at the file for a bit, but nothing jumped out at me.
What to do???
When all else fails, RTFM !!!
[Read The Fine Manual, :-)].
>From IBM's sdkguide.lnx.htm:
|If your system locale is using a UTF-8 encoding, some SDK
|tools might throw a sun.io.MalformedInputException. To find out
whether your |system is using a UTF-8 encoding, examine the
locale-specific environment |variables such as LANG or LC_ALL to
|see if they end with the suffix ".UTF-8". If you get this
sun.io.MalformedInputException, |change characters that are not
within the 7-bit ASCII range (0x00 - 0x7f) |and are not
represented as Java Unicode character literals to Java Unicode
|character literals (for example: '\u0080'). You can also work
around this |problem by removing the ".UTF-8" suffix from the
locale-specific environment |variables; for example, if your
machine has default locale of "en_US.UTF-8", |set LANG to
"en_US". | |
Note:
|
Some distributions |of RedHat, including Redhat9 and RHEL3, use
UTF-8 encoding by default.
Looks like some changes need to be made to the locale-specific
environment for YDL-4. I renamed the environment variable, which allowed
the java compilation to succeed.
Onwards,
-Joseph
--
joseph_sacco[at]comcast[dot]net
More information about the yellowdog-general
mailing list