dischord:/home/btp/proj/chartest 43 % uname -a
SunOS dischord 5.6 Generic_105181-12 sun4m sparc SUNW,SPARCstation-20


Using JDK 1.2.2 with various localizations, the characters 0xdc00 and soon there after behave strangly.

When cycling through characters and outputing them, characters just prior return a single question-mark (or other "unknown" character on other systems). Once 0xdc00 is come to, lines and lines and lines of "unknown" characters are output. Then, the variable ceases to incrememnt outputting these lines of "unknowns" over and over again.


The results came up under Japanese and Chinese locales. Further testing, in progress.

Attached is a some simple source that demonstrates. Change the initial value to numbers soon there after (recompile) and view similar results.

----end original--
----appended 7/15
In an AWT application of mine, when trying to execute the following code:

 //extract valid character and display it in the proper field
 //hexField and small are of class TextField, smallBoxData is a char,
 // smallInt is an Integer, MessageDialog is a class of mine


                String tmpString = new String(hexField.getText());
                try {
                   smallBoxData = (char) smallInt.parseInt(tmpString, 16);
                } catch (Exception e4) {
                   System.out.println("Error e4: " + e4.toString());
                   MessageDialog credits = new MessageDialog (
                        "Warning", "Invalid hex (0-f)");
                }

                tmpCharArray[0] = smallBoxData;
                small.setText(new String(tmpCharArray))


I recieved the following errors to the terminal:
Exception occurred during event dispatching:
java.lang.InternalError: Converter malfunction: sun.io.CharToByteEUC_CN
        at java.lang.String.getBytes(String.java, Compiled Code)
        at java.lang.String.getBytes(String.java, Compiled Code)
        at sun.awt.motif.MTextAreaPeer.setText(Native Method)
        at java.awt.TextComponent.setText(TextComponent.java, Compiled Code)


---added later on that day
The upper bound seems to be 0xdfff