Community
Participate
Working Groups
Usign the phoneme virtual machine on windows mobile 6.1 I get some undreadable characters added randomly at the end of some labels. The issue has been described better than i would be able to in a comment of the post: http://jmj-eclipse.blogspot.com/2009/10/running-ercp-with-phoneme-advanced-on.html as: "I was able to resolve the issue with stray characters in the widget texts (menu, button, etc.) by fixing one method in the eSWT C code. It seems CVM does not handle Strings the same way J9 does. J9 will automatically terminate the string with null values when passing to/from JNI. CVM doesn't seem to do this. The fix was pretty simple, since the length of the string was provided already..." The problem has been touched also in the post: http://jmj-eclipse.blogspot.com/2009/09/phoneme-advanced-and-eswt-running-under.html as: "After intensively debugging, I find the problem exists in the #GetStringChars() method. This method return the jchar* which is called by #convertToNativeString, however this implementation in CVM seem has a non-standard behavior. (I am not sure to open this bug to eswt? or cvm?)..."
An update on the issue. One of the PhoneME developers was so kind to look into the problem to check if this is a eSWT or phoneME bug (thanks Davy Preuveneers). It looks like the issue in the eRCP tracker is in the right place. It turnes out that in: stringCharData = GetStringChars(env, string); if (ExceptionCheck(env)) return ; stringLength = GetStringLength(env, string); uglstring = convertToNativeString(stringCharData, stringLength, &stringShouldFree); error.error_code = 0; GetStringChars is a JNI method. In that case phoneME returns a non-null terminated pointer to a jchar array (a Unicode string). Then convertToNativeString() transforms this jchar array into an internal representation, but mistakenly assumes that stringCharData is null-terminated. This method is implemented in eSWT and can be found in: http://dev.eclipse.org/viewcvs/viewvc.cgi/org.eclipse.ercp/eswt/win/org.eclipse.ercp.swt.core.win/win-native/bindings/impl/TypeConverter.c?root=RT_Project J9 makes sure that all Unicode strings are null-terminated and the eSWT code relies on it. Which is why J9 doesn't have the problem. So to summarize it seems that eSWT wrongly assumes GetStringChars returns null-terminated strings where it should not. Unicode strings are not \0 terminated, whereas UTF-8 strings are (and GetStringChars uses Unicode strings) See sectopm 3.2.4 in: http://java.sun.com/docs/books/jni/html/objtypes.html
