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.
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
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.
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.
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
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.
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.
Radko, could you look at this, it affects Java ME SDK as well?
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.
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.
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
Verified ... and Closing all issues resolved into NetBeans 6.7 and earlier.