Re: [jira] Commented: (HARMONY-6408) [classlib][luni]OutputStreamWriterTest got java.nio.BufferOverflowException

[Ray Chen <cl...@gmail.com>]

Hi Regis,
> Do you mean the value of property "file.encoding"? It's set at
> modules/luni/src/main/native/luni/shared/luniglob.c:159

Yes, Thank you!

>
> We first check whether the value is NULL, if so, call getOSCharset to get
> default value from OS ( you can reference HARMONY-6279 for more details). I
> guess IBM vm set the value to GB18030, but drlvm doesn't set it, and then we
> use getOSCharset, get a different charset. The charset should be same with
> your local setting. According to you previous comments on JIRA, seems GB2312
> is correct.
>

For this part, the situation is a little complicated:
First use following simple test case:
public class Harmony6408TestCase {
	public static void main(String[] args) {
		System.out.println("file.encoding in java : " +
System.getProperty("file.encoding"));
	}
}

I also added some printf debug statement in luniglob.c, certainly add
to the file.encoding part as following:

       /* Many classes depend on correct "file.encoding" value */
       if(propVal != NULL){
    	   printf("file.encoding: %s\n", propVal);
       }
       if (propVal == NULL) {
           /* FIXME provide appropriate non-dummy value */
           getOSCharset(charset, CHARSETBUFF);
		   printf("charset: %s\n",charset);
           propRes = (*vmInterface)->SetSystemProperty (vmInterface,
"file.encoding", charset);
           if (VMI_ERROR_NONE != propRes) {
               /* goto fail2; */
           }
       }

I ran the test case on trunk and got the output:
file.encoding in java : null
file.encoding: GMT+8:00

I ran the test case on java6 branch and got the output:
file.encoding in java : gb2312
charset: gb2312

I think for this part java6 branch's behavior is right. In trunk,
propVal seems still holding user.timezone property which means
"(*vmInterface)->GetSystemProperty (vmInterface, "file.encoding",
&propVal);" doesn't set propVal to NULL (I think it should if it can
not get the file.encoding property);

So that we got the result,
When the test ran on the trunk, the
System.getProperty("file.encoding"); got null and in
OutputStreamWriter it uses default encoder (ISO-8859_1) which makes
the test case pass.
When the test ran on java6 branch, the
System.getProperty("file.encoding"); got GB2312, which makes the test
case failed.

So here is the question, since trunk and java6 branch shared same
DRLVM, why got different result when invoke
"(*vmInterface)->GetSystemProperty (vmInterface, "file.encoding",
&propVal);"  ?


> And I think we should fix the test not to depends on local environment.
>
Yes, I do agree, however, this issue seems that there are really some
bugs in our classlib or DRLVM code, and for Chinese users, it should
use GBK or GB18030 for default encode instead of GB2312

> --
> Best Regards,
> Regis.
>



-- 
Regards,

Ray Chen