[news.eclipse.dsdp.ercp] Re: Display problem running on some VMs

["Tom GROSMAN" <grosman@xxxxxxxx>]

Will do.

Thanks,

Tom


"Gorkem Ercan" <gercan@xxxxxxxxxxxxxxx> a écrit dans le message de news: 
h4pf56$fog$1@xxxxxxxxxxxxxxxxxxxx
> Tom GROSMAN wrote:
>> Hi,
>
> Hi Tom,
>
> This sounds like a bug. Can you please report it 
> here(https://bugs.eclipse.org/bugs/enter_bug.cgi?product=ERCP) so that the 
> development team can attend to it.
>
> As a note this newsgroup has been moved to eclipse.ercp newsgroup.
> --
> Gorkem
>
>>
>> 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