Re: [Wrapper-user] RE: JNI on Win 2000

[Leif M. <le...@ta...>]

Lakshmanan,

>	I dont have full development environment in my laptop for the jni
>library. So i will add the printf statements tomm.
>  
>
Ok, let me know the results when you are able to make those changes.

>	I made a change to the service. I made the service use the same user
>as that of the standalone application uses (instead of the system user),
>even then the same problem repeats.
>
Thanks for testing that.  That eliminates some possible causes. :-/ 

>  I have Locale set to English. I dont
>even have japanese locale installed in my machine.
>  
>
I didn't expect that you were running Japanese. :-)  But other 
non-english locales also
have similar problems.  Double byte locales are just an order of 
magnitude more
complex.

Cheers,
Leif

>Thanks
>Lakshmanan
>
>-----Original Message-----
>From: Leif Mortenson [mailto:le...@ta...]
>Sent: Friday, February 20, 2004 8:53 AM
>To: wra...@li...
>Subject: Re: [Wrapper-user] RE: JNI on Win 2000
>
>
>Lakshmanan,
>Would it be possible for you to modify your C code as follows:
>    printf("---BEGIN---\n");
>    printf("%s\n", pTransferStr);
>    printf("----END----\n");
>    flushall();
>    return (*env)->NewStringUTF(env, pTransferStr);
>
>It looks like the character encoding is getting confused somewhere along 
>the way.
>Not sure why that is happening as they appear to be simple ascii 
>characters.  The
>above code will verify that the string has the expected value while 
>still in C.  The
>flush is required to get the output to actually be sent immediately to 
>the console
>and thus the Wrapper.
>
>For now, I am going to assume that the above code will show the same 
>thing in
>both runs and that the problem is in the creation of the String using the
>NewStringUTF call.  What is the locale of your machine?  Is it 
>English?   I have
>had problems with character sets in C while working with the Japanese locale
>before.  The fact of the matter is that it is much easier to work with 
>character
>encodings in Java.  For this reason, when I have worked with Strings 
>with JNI
>in the past, I always pass the string into the JVM as a byte[].  It is 
>then easy
>to create a string object within the JVM using new String(bytes, 
>"encoding");
>In most cases, the default encoding works new String(bytes);
>
>I am also wondering what is going on though, so lets keep trying to get the
>NewStringUTF method working.
>
>Another test would be to call getBytes on the string you obtain from JNI and
>then display their values to the console.  By comparing this output you 
>can verify
>that the problem is happening in the NewStringUTF call and not someplace 
>later.
>Use getBytes( "8859_1" ); so we can guarantee that the same character set is
>being used in each case.
>
>The NwStringUTF call assumes that the raw byte array contains UTF-8 encoded
>characters.  The only thing that I can think of is that maybe they are 
>not actually
>UTF-8 characters in both cases?   When as a service, the Wrapper is 
>running as
>the SYSTEM user along with all of its environment settings.  When run as a
>console, it is running as you.
>
>These things can be quite difficult to track down.  Dumping the raw byte 
>values as
>numbers both before and after the transition from C to Java should help 
>to locate
>exactly where the problem is arising.
>
>Turned into a ramble, but I write as I think. :-)
>
>Cheers,
>Leif
>  
>