Community
Participate
Working Groups
I'm using 2.1 RC1. Debug some program. Type "\012\015", select the string an choose "Inspect" from the context menu. It tells you that this string has 6 characters, an unidentifiable char (probably 0), a '1', a '2' and so on. Of course the string should contain only two characters, namely "\n\r". The compiler and the scrapbook evaluator do it right. The debug inspect has no problems with "\n\r". It has problems with "\u000a" but that's probably a different bug to report. The debug inspect has even more problems with character constants - it ignores them. You cannot inspect them. You can inspect them in the scrapbook though.
The scrapbook actually compiles into classfiles (and the compiler does the conversion for us). The debugger evaluations are done via an interpreter. Thus, the difference.
Luc, do you know if there is any "simple" way we can get this type of pre- processing from the compiler (i.e. constant conversions)? (My feeling is that we will have to defer this one for post 2.1 consideration).
I think it's a jdt-core bug. I entered a new bug (bug 33450).
Stefan: just for information, the behavior you see with "\u000a" is not bug, it behave how it's describe in the java language specification. The unicode escape sequences have to be replace before the 'real' parsing begins. \u000a will be replace by a linefeed. String s= "test\u000atest"; is equivalent to String s= "test test"; which is invalide in Java.
The jdt-core bug has been fixed. We have to add a regression test to the eval test suite.
No need for a test, it's a jdt-core problem, they have a regression test.
