When I run the example programs (hello, demo, ...) on VMs other than
Hotspot I run into a problem displaying characters. The text strings are
displayed with unprintable characters in the string (see
http://twitpic.com/btl82 for an example). I have seen this sort of thing
before when a non-null terminated string is retrieved via the jni call
GetStringChars and used directly.
Section 10.8 of the JNI Programmers Manual and Specification states:
10.8 Terminating Unicode Strings
Unicode strings obtained from GetStringChars or GetStringCritical are not
NULL-terminated. Call GetStringLength to find out the number of 16-bit
Unicode characters in a string. Some operating systems, such as Windows NT,
expect two trailing zero byte values to terminate Unicode strings. You
cannot pass the result of GetStringChars to Windows NT APIs that expect a
Unicode string. You must make another copy of the string and insert the two
trailing zero byte values.
The jni code in eRCP incorrectly assumes that the string returned from
GetStringChars is null terminted and that the value of GetStringLength
includes the null byte at the end-
stringCharData = GetStringChars(env, javaString0);
if (ExceptionCheck(env)) return modifiedText;
stringLength = GetStringLength(env, javaString0);
modifiedText = convertToNativeString(stringCharData, stringLength,
shouldFreeString);
convertToNativeString calls g_utf16_to_utf8 which adds a single 0 byte.
Apparently Hotspot does not follow the specification and returns a
null-terminated string and a corresponding length. eRCP works with Hotspot
but does not follow the JNI spec and therefore does not work with VMs which
do follow the specification.
Do you agree with my analysis? Should I file a bug (against which
component?). Any chance it will get fixed, seeing as how it already works
with Hotspot?
Thanks
Tom GROSMAN