It's a tool problem. But figuring out exactly what part of the tool is buggy is hard. If I'd have figured out what the problem was (probably spending hours),

It's a tool problem. But figuring out exactly what part of the tool is buggy is hard. If I'd have figured out what the problem was (probably spending hours), and reported it, the javac people would've said, "javac is working just fine, you specified the wrong locale." The Eclipse people would've said, "Eclipse is working just fine, it uses the system locale as a default when you don't specify." The Ubuntu people would have said, "Our locale setup is fine, it's your fault for not selecting ISO-1234-5678 instead of or in addition to UTF back when you installed the system. Oh, and of course you also have to set your environment variables correctly..." The author would have said, "I'm using a normal system and it compiles fine for me. If I change encoding so it compiles for you, it breaks on my system!" The upshot is, the tool support is garbage, because you have to jump through a bunch of hoops to get code to compile. I recall the error messages not being helpful. (Would it be so hard for the compiler to say "Warning: Unrecognized character o.., it looks like you're using ISY-2358 encoding even though you didn't specify. To make this warning go away, enable the ISQ-1337 locale, regenerate your locales, and set the LC_ALL environment variable.") Being able to compile a given piece of source code into object code should not break if you change obscure environment settings between machines. Spending hours figuring out what's breaking, only to find out that things aren't breaking and I have to change a bunch of settings on every development machine I use (with different values for every program I compile, of course), is a lot more effort than just limiting your source files to character codes less than 128 (or 126 or whatever the top ASCII character is).