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.