UTF-16 support

Question

I'd like to determine what non-Latin characters can be displayed on my handset. Using the encoding UTF-16BE does not throw an exception and I can create Latin characters and basic symbols. However when I try Greek, Hebrew, and such the generated strings are blank.
I understand that full UTF-16 support is the manufacturer's preference, however these characters are displayed elsewhere in the UI (e.g. if I change languages). What's more, I've been told the phone UI is written in Java, though I can't confirm.
I imagine the problem could be a one of several levels:
1. The extended characters are accessible through some other encoding, just not UTF-16.
2. My code uses LWUIT, perhaps it cannot render these characters.
3. Extended characters aren't supported on the phone's JVM even though the native UI uses them.

Answer 1

Dude,
UTF-8: I'm looking to represent Asian symbols so unless I'm horribly wrong those aren't in UTF-8.Please have a look at [this UTF8 table|http://www.atm.ox.ac.uk/user/iwi/charmap.html] At my work place we have software that uses Traditional and Simplified Chinese, Thai, Vietnamese, Greek, Russian and few more and all are achieved using UTF8.
Source values: I've dumbed it down as much as possible, by creating hard coded strings with various byte values. I can be confident in the syntax, endianness, and signed byte issues because a the Latin portion of UTF-16BE works fine. Does it mean that your string has value similar to: u023f,u002d,... and you do parsing of that to a byte array and then creating the String object by using this byte array and correct encoding identifier? Or do you hardcode the string you want to display using the actual characters? In second approach you have to make absolutely sure that your code editor or IDE (Eclipse, Netbeans, ...) use exactly the encoding that you are trying to achieve. Even when the text is correctly displayed on the computer screen does not guarantee that it will be saved and read using the same encoding, which you can appreciate is essential here.
Again I urge to use the UTF8 encoding in order to be sure about the font support. It is the simplest to implement of all Unicodes and for that reason vendors would choose it over any UTF-16.
Java native UI: This is just hearsay I've picked up. If this is the case, it's plausible that Samsung is running a JVM for the UI and another for client games and apps. It certainly makes sense from a mfg cost standpoint. It's sorta immaterial, other than being definite proof that the extended encoding exists in the Java libraries.JVM is a quite sizeable thing to run in order to get the UI. What would be the scenario if your Java UI threw an exception? I am not native app/UI expert, but unless Java is a integral part of the core system (like in Android), UI stays native. Again, I might be wrong here at it really does not matter in the context of your problem.