Make javac.py assume UTF-8 encoding always

Make javac.py assume UTF-8 encoding always

My understanding is that by-default javac
pulls encoding from the user's environment
http://stackoverflow.com/questions/9661935/how-to-change-the-defaults-system-java-encode-form-in-windows
http://stackoverflow.com/questions/11343828/file-encoding-has-no-effect-lc-all-environment-variable-does-it
which is wrong for Chromium where all of our
source files are known to be UTF-8, regardless
of what the user has set in their environment.

In my case I was using Chrome Remote Desktop
to connect to my linux machine and for
whatever reason LANG was missing from the
resulting environment.  After this patch
mojo_shell builds correctly for Android again.

BUG=419378
Committed: https://crrev.com/32170ad8a272b81d05ccce1d69473ca20d18a16e
Cr-Commit-Position: refs/heads/master@{#313432}

[eseidel, 2015-01-22 20:20:09]

eseidel@chromium.org changed reviewers:
+ jbudorick@chromium.org

[jbudorick, 2015-01-22 20:23:10]

jbudorick@chromium.org changed reviewers:
+ cjhopman@chromium.org

[jbudorick, 2015-01-22 20:23:11]

+cjhopman

[cjhopman, 2015-01-22 21:02:08]

cjhopman@chromium.org changed reviewers:
+ andrewhayden@chromium.org

[cjhopman, 2015-01-22 21:02:09]

+andrewhayden

I just de-duped the bug against another one (https://crbug.com/419378) where
andrew makes the argument that we should actually by forcing ascii encoding
here. What do you think for/against that?

We should definitely be forcing some encoding here so that we don't have these
different behaviors in different environments.

[eseidel, 2015-01-22 21:12:35]

That's fine, but we'll need to fix this java file (and likely others) if we move
to ASCII:
https://github.com/domokit/mojo/blob/master/mojo/android/javatests/src/org/ch...

[Andrew Hayden (chromium.org), 2015-01-23 11:10:08]

On 2015/01/22 21:12:35, eseidel wrote:
> That's fine, but we'll need to fix this java file (and likely others) if we
move
> to ASCII:
>
https://github.com/domokit/mojo/blob/master/mojo/android/javatests/src/org/ch...

I stand by my assertion that we should force ASCII. Raw UTF8 could still be
valid (but different) character data in non-UTF8 charsets. Using ASCII should
force the correct behavior in all cases.

Regarding fixing other source files: Couldn't we just write a python script to
scan an arbitrary file as UTF8 and replace all non-ascii characters (value >127)
with their unicode escape sequence? This seems like a totally mechanical change.

[eseidel1, 2015-01-23 13:13:34]

eseidel@google.com changed reviewers:
+ eseidel@google.com

[eseidel1, 2015-01-23 13:13:34]

Shrug.  For what its worth the google style guide appears to assume utf8:
http://google-styleguide.googlecode.com/svn/trunk/cppguide.html#Non-ASCII_Cha...

And we explicitly mention to use utf8 for Chromium:
http://www.chromium.org/developers/coding-style#TOC-Non-coding-miscellany

I don't think it's worth the hassle of doing ASCII everywhere.

[eseidel1, 2015-01-23 13:15:03]

I guess my point is if you'd like to change the rules for java files to be ASCII
we should update at least the Chromium style guide to say so. :)  Otherwise we
should just fix our tools to assume UTF8 like at least that wiki page claims.

[Andrew Hayden (chromium.org), 2015-01-23 13:18:54]

On 2015/01/23 13:15:03, eseidel1 wrote:
> I guess my point is if you'd like to change the rules for java files to be
ASCII
> we should update at least the Chromium style guide to say so. :)  Otherwise we
> should just fix our tools to assume UTF8 like at least that wiki page claims.

I added a comment to the bug. I'm ok with UTF-8, but we should probably just
make a note somewhere that people should ensure that their *editors* are using
UTF-8 as well, so they don't end up jamming something that happens to be valid
UTF-8 (but isn't what they think it is...) into the code.

[cjhopman, 2015-01-28 00:43:26]

lgtm

[cjhopman, 2015-01-28 00:45:40]

On 2015/01/28 00:43:26, cjhopman wrote:
> lgtm

I don't think we should deviate from the stated position on chromium.org.

[eseidel, 2015-01-28 00:49:42]

The CQ bit was checked by eseidel@chromium.org

[commit-bot: I haz the power, 2015-01-28 00:50:56]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/869673002/1

[commit-bot: I haz the power, 2015-01-28 04:13:16]

Committed patchset #1 (id:1)

[commit-bot: I haz the power, 2015-01-28 04:14:25]

Patchset 1 (id:??) landed as
https://crrev.com/32170ad8a272b81d05ccce1d69473ca20d18a16e
Cr-Commit-Position: refs/heads/master@{#313432}