UTF-8 (BOM) prevents java compilation

I had an adventure tracking this one down lately, it seems that if your IDE saves files as UTF-8, the java compiler can’t always resolve the files.

Here’s the errors from the console output:

[INFO] ————————————————————————
[INFO] ————————————————————————
[INFO] Compilation failure

C:\Sandbox\Jars\example.jar\src\main\java\com\giantgeek\Example.java:[1,0] ‘class’ or ‘interface’ expected

C:\Sandbox\Jars\example.jar\src\main\java\com\giantgeek\Example.java:[1,1] illegal character: \187

C:\Sandbox\Jars\example.jar\src\main\java\com\giantgeek\Example.java:[1,2] illegal character: \191

Those character codes (\187 \191) may look a little familiar to some people, as they represent the Byte Order Mark (BOM) that prefixes a UTF-8 formatted file. If you look at them in a file editor (or text editor that doesn’t interpret UTF-8) they will look odd.

They look like “an i (two dots over), double right arrow, upside down question mark”.

Simple solution is to re-edit and save the file as ISO-8859-1.

An alternate approach that is available in some instances is to use the arguments to javac to allow the file encoding.



Open Source Text Editors

As an old UNIX developer, I spent a significant portion of my work experience using VI, as my development environment became more focused on Windows, I used Homesite for developing text formatted documents. I’ve found that the current offerings from Eclipse and other IDE’s are notoriously bad at displaying the source of many document types, particularly JSP, HTML, XML, JAVA, JS and CSS files; where you often want to see exactly how a document is structured. Additional spaces, tabs and carriage returns can cause display formatting issues and wasted bandwidth in many cases.

Many of my peers are fans of TextPad, but I’ve found Notepad++ to be quite up to the task:

  • it is available for Windows and LINUX
  • supports auto-formatting of many text file types
  • can ‘replace’ the default Source-HTML viewer in MSIE.


Happy coding!