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.
NB : 6.5 JavaFX : 1.0 plugin OS : Windows XP Japanese Encoding of project is set to windows-31j for workaround. It seems that parsing JavaFX codes fails when it contains Japanaese characters. Color highlighting is not correct on editor. Fixing import and format codes on editor in such situation causes unexpected deletion, users codes will be lost. I'll attach the sample project and scheenshots.
Created attachment 75336 [details] sample project, contains two JavaFX files. Try it with windows-31j encoding
Created attachment 75337 [details] screenshot : wrong code coloring, error underline is showing in this case. Changing Japanese to ascii will fix it.
Created attachment 75338 [details] screenshot : wrong code coloring - " is wrong color.
Created attachment 75339 [details] fix import, format code causes unexpected deletion of user codes.
Rasta, can you please check this one?
Lowering priority. This happens only on special combination of ENV and characters in file.
I don't think it's a rare case, most users are using Japanese in JavaFX codes on Windows platform. Once this issue happens, it slows down the IDE performance.
The interesting thing is that when I use UTF-8 encoding in IDE (not source encoding) via setting "-J-Dfile.encoding=UTF-8" option, this error does not happen. $ netbeans IDE uses ShiftJIS on Japanese Windows. It causes this parse error. $ netbeans -J-Dfile.encoding=UTF-8 I can not see this issue. The project(source) encoding does not matter. On Mac, the default encoding of Java is UTF-8 on JDK5, ShiftJIS on JDK6 in Japanese environment. So the issue happens when users are using JDK6.
I'm sorry the last comment was not correct. Using -Dfile.encoding=UTF-8 only solved the issue in the sample project attached before (JavaFXApplication1.zip). Using -Dfile.encoding=UTF-8 changed the behavior but there are another cases. I'll attach sample project. I'm trying to see source codes, it seems that the following line should be changed to specify the encoding. I think that's why it depends on file.encoding. javafx.lexer/src/org/netbeans/lib/javafx/lexer/JFXLexer.java: - ANTLRReaderStream input = new ANTLRInputStream(reader); + ANTLRReaderStream input = new ANTLRInputStream(reader, "UTF-8"); Another issue is that it seems that input.LA(1) in v4Lexer.java does not return multibytes properly. I don't know why, when the data is loaded, these data are properly stored, however input.LA() is not correctly returning. If data is "\u307b" but it looks the following input.LA(1) in mDoubleQuoteBody() returns only 0x7b. int LA5_0 = input.LA(1);
Created attachment 77052 [details] another example for UTF-8 locale
reassigning to new owner.
It seems that the root cause is, read() is not implemented to return a byte in LexerInputStream. LexerInputStream extends InputStream, static class LexerInputStream extends InputStream { so the read() method needs to return a byte, not a character. http://java.sun.com/javase/6/docs/api/java/io/InputStream.html#read() Applications that need to define a subclass of InputStream must always provide a method that returns the next byte of input. Currently read() returns a character by reading the contents of editor, the contents are already encoded to corresponding characters, but byte is expected as return value so the character is corrupted. It seems that ANTLRInputStream() accepts only InputStream, so I think we need to make read() return a byte. I could not find any methods for reading bytes from editor contents, so I made very simple patch in read() method. It's just an example. It's not good code. I didn't care the performance and errors, but it's working for me, unexpected error stripe and wrong coloring disappear. Could you please check the patch and think the better and reasonable fix?
Created attachment 77890 [details] patch for returning a byte by read() of LexerInputStream
The proposed patch contains a bug - whenever Lexer reaches EOF the rest of the "si" queue is not returned. Also using ArrayList.remove(0) for the queue implementation is a performance issue. I'll check for the possible fix.
Created attachment 77900 [details] this patch should work better
fixed
Great! Thank you for fixing! I built it locally and tried on Windows and Mac. It works for now, performance is also really better than mine.
On my environment, it's now working fine.