This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.

Bug 161977 - Problem converting '\u0000'. See Decsription
Summary: Problem converting '\u0000'. See Decsription
Status: CLOSED WONTFIX
Alias: None
Product: debugger
Classification: Unclassified
Component: Java (show other bugs)
Version: 6.x
Hardware: Sun Windows XP
: P1 blocker (vote)
Assignee: issues@mobility
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2009-04-05 10:29 UTC by silvioturrini
Modified: 2010-04-29 09:49 UTC (History)
2 users (show)

See Also:
Issue Type: DEFECT
Exception Reporter:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description silvioturrini 2009-04-05 10:29:29 UTC
Netbeans 6.5.1 jdk1.6.0_13
Problems running old version of MIDlet code because wong encoding with strings with special chars ( using escaped 
notation: \u0000 )
Example:

 String str = "mystring\u0000\u0000\u0000\u0000";  // "mystring" followed by 4 '\u0000' chars, but even one ...

In old versions ( Netbeans 6.0, 6.1 and old version of Java: jdk1.6.0_04 ) everything was fine and the last chars have 
been converted into '\u0000' as expected. In the new version the last chars get converted into '\ufffd' !
Changing compiler encoding didn't make any difference.
Same thing happens if you try to build a string using the String constructor and passing, for instance, a byte array
with all 0x00 ( specifying the encoding ). Everything gets converted into '\ufffd' instead of '\u0000'. Even using char 
array won't change the problem. Maybe javac should be called as: javac.exe -encoding UTF-8 xxxxxx and I thought it was 
what the compiler options where all about, but it isn't working or simply it is another issue.
I didn't check with other escape sequences, but I guess other "non printable" chars will be affected by the same 
problem. Either is a compiler issue and there must be a work around, or is a "non wanted" behaviour that must be 
corrected soon!

Thank you
             Silvio Turrini
Comment 1 Petr Suchomel 2009-04-06 08:24:10 UTC
Looks to me as an compiler issue. Could you please test with latest (M3) NetBeans 6.7 and java version which worked for
you? Could you also attach some test cases? Thanks.
Comment 2 Andrei Chistiakov 2009-04-06 15:38:11 UTC
Product Version: NetBeans IDE Dev (Build 200904011705) (M3)

To reproduce the issue:
- create mobile application;
- add MIDlet to the project;
- add the following 2 lines in startApp() method:
        String str = "mystring\u0000";
        int i = 1;
- set break point at the second line;
- debug the application;
- when debugger hits the breakpoint, inspect value of str vatiable. 

The value is "mystring\ufffd\ufffd" when using JDK 1.6.0_12, 1.6.0_13 and "mystring\u0000" with JDK 1.6.0_04, 1.5.0_12.

The issue is not reproducible with similar Java SE project.

Comment 3 Petr Suchomel 2009-04-07 10:13:12 UTC
Seems to be debugger related issue (maybe masking error or so), if you try the code itself, it works correctly:
        String str = "mystring\u0000";
        int i = 1;
        for (int n = 0; n < str.length(); n++){
            int c = str.charAt(n);
            System.out.println(Integer.toHexString(c));
        }
Prints same results on both JDK's
Comment 4 Petr Suchomel 2009-04-07 10:30:33 UTC
It really looks like some issue with debugger, I also tried to run WTK on different JDK's, same results. Same issue also
with Java ME SDK 3.0.
Reassigning to debugger guys to look at it.
Comment 5 Martin Entlicher 2009-04-07 20:25:44 UTC
I have reproduced the problem.
However, I do not think it is fixable in NetBeans. So far it looks like JDI is returning the value we provide. We've no
chance to test if it's a correct value or not.
I've also tested other characters like \u0001, \u0020, \u1000, \ufffd, \uffff, but it seems like only \u0000 suffers
from this problem. And BWT: "char c = '\u0000';" is displayed correctly.
I doubt this is P1 priority.

I'll keep investigating where the false value comes from, but so far I think that this ends up as won't fix.
Comment 6 Petr Suchomel 2009-04-08 10:11:26 UTC
Radko, could you look at this, it affects Java ME SDK as well?
Comment 7 Martin Entlicher 2009-04-08 14:55:35 UTC
The bug is not in NetBeans nor in JDI layer. The defect seems to be in the J2ME backend.

When I ask for the string "mystring\u0000" in J2SE project (JDK 1.6.0_10 or 1.6.0_12) I get:

[JDI: Receiving Reply. id=6171, length=13, errorCode=0, flags=128]
[JDI: 0000: 00 00 00 09 6d 79 73 74 72 69 6e 67 00 ]
[JDI: Receiving Command(id=6171) JDWP.StringReference.Value]
[JDI: Receiving:                stringValue(String): mystring]
[JDI: Receiving:                    values[i](ValueImpl): "mystring"]

Please note that the hexadecimal codes that represent the string ends with "00", which represents \u0000.

But when I debug J2ME, I get following reply for the same string:

[JDI: Receiving Reply. id=5865, length=14, errorCode=0, flags=128]
[JDI: 0000: 00 00 00 0a 6d 79 73 74 72 69 6e 67 c0 80 ]
[JDI: Receiving Command(id=5865) JDWP.StringReference.Value]
[JDI: Receiving:                stringValue(String): mystring��]
[JDI: Receiving:                    values[i](ValueImpl): "mystring��"]

Please note that the string is now longer! The length is not "09", but "0a". Also it ends with "c0 80", not "00" as it
should. Therefore this translates to a different string ("mystring\ufffd\ufffd" does not seem to be correct either, but
I'm not a Unicode expert).

Looking into sun.nio.cs.UTF_8.java proved that current behavior (in JDK 6 u12 and newer) is correct. The algorithm was
modified to fix http://bugs.sun.com/view_bug.do?bug_id=4297837. This correction was because of
http://www.unicode.org/versions/corrigendum1.html

Specifically following functionality was removed:
"a UTF-8 conformant mayt map the code value sequence C0 80 (110000002 100000002) to the Unicode value U+0000, even
though a UTF-8 conformant process shall never generate that code value sequence -- it shall generate the sequence 00
(000000002) instead."

Therefore translation of "c080" to \u0000 done in older JDK should not be done any more.

J2ME backend should be fixed to provide "00" instead.
Comment 8 Martin Entlicher 2009-04-08 15:36:52 UTC
I've submitted defect for J2ME, it should be visible in a few days at http://bugs.sun.com/view_bug.do?bug_id=6827826.
Comment 9 Petr Suchomel 2009-04-08 18:25:27 UTC
Looks as a KDP problem, wrong reading of constant pool UTF8 symbols. See more details in
http://www.netbeans.org/issues/show_bug.cgi?id=162168
Comment 10 Quality Engineering 2010-04-29 09:49:53 UTC
Verified ... and Closing all issues resolved into NetBeans 6.7 and earlier.