Remove ICU usage from jni_helpers.cc.

Remove ICU usage from jni_helpers.cc.

JNI already has jstring<->UTF8 string conversion, so using that should
save ~1mb off android binaries (ICU is *large*), probably around
300-400k after compression.

BUG=

Committed: https://crrev.com/23725e09c6533739afa67ca9694f6fa874c26279
Cr-Commit-Position: refs/heads/master@{#10545}

[noahric, 2015-11-05 22:32:40]

noahric@chromium.org changed reviewers:
+ glaznev@chromium.org, mflodman@webrtc.org, tommi@chromium.org

[noahric, 2015-11-05 22:32:40]

Alex: you'll probably want to verify this manually, since I doubt there are
tests to make sure the conversion is correct.

I hunted down history to see if there was a reason for using it, but it's there
in the original version, so I'm guessing it was just a simple overlooking of the
UTF functions.

Including patrik and henrik as FYI, in case it has other build rammifications.
And magnus for toplevel webrtc and tommi for toplevel talk.

[phoglund, 2015-11-06 08:08:05]

phoglund@webrtc.org changed reviewers:
+ phoglund@webrtc.org

[phoglund, 2015-11-06 08:08:05]

Nice work. I wanted to look at removing ICU as well but it looks like you saved
me that work :) It's a lot of trouble in google3 so getting rid of it is a big
win.

[kjellander_webrtc, 2015-11-06 11:02:22]

kjellander@webrtc.org changed reviewers:
+ kjellander@webrtc.org

[kjellander_webrtc, 2015-11-06 11:02:22]

Wow, this is truly great. I've also wished for someone to remove this
dependency.
lgtm

[kjellander_webrtc, 2015-11-06 11:05:05]

You could also try removing icu from setup_links.py and .gitignore but I'll be
happy to do that in a follow-up CL instead.

[AlexG, 2015-11-06 17:49:59]

lgtm

[noahric, 2015-11-06 21:51:18]

The CQ bit was checked by noahric@chromium.org

[commit-bot: I haz the power, 2015-11-06 21:51:30]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1430023005/60001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1430023005/60001

[commit-bot: I haz the power, 2015-11-06 21:56:09]

Committed patchset #4 (id:60001)

[commit-bot: I haz the power, 2015-11-06 21:56:18]

Patchset 4 (id:??) landed as
https://crrev.com/23725e09c6533739afa67ca9694f6fa874c26279
Cr-Commit-Position: refs/heads/master@{#10545}

[jridges, 2015-11-06 22:44:17]

jridges@masque.com changed reviewers:
+ jridges@masque.com

[jridges, 2015-11-06 22:44:17]

Saw this go by and had to comment. A careful reading of the JNI spec. shows that
the JNI does not produce standard UTF-8, but a modified form. I don't know if
that's important in this case or not, but it should probably be documented.

[noahric, 2015-11-07 01:48:17]

On 2015/11/06 22:44:17, jridges wrote:
> Saw this go by and had to comment. A careful reading of the JNI spec. shows
that
> the JNI does not produce standard UTF-8, but a modified form. I don't know if
> that's important in this case or not, but it should probably be documented.

Do you have a link? That's really interesting to know. I very much doubt it'll
make a practical difference for how it's used here (limited, non-user-visible
string parsing), or that very many projects ship a separate unicode library to
support it, though :) Thanks!

[jridges, 2015-11-07 03:01:53]

On 2015/11/07 01:48:17, noahric wrote:
> On 2015/11/06 22:44:17, jridges wrote:
> > Saw this go by and had to comment. A careful reading of the JNI spec. shows
> that
> > the JNI does not produce standard UTF-8, but a modified form. I don't know
if
> > that's important in this case or not, but it should probably be documented.
> 
> Do you have a link? That's really interesting to know. I very much doubt it'll
> make a practical difference for how it's used here (limited, non-user-visible
> string parsing), or that very many projects ship a separate unicode library to
> support it, though :) Thanks!

The wikipedia article on the JNI rather succinctly describes the issue:

https://en.wikipedia.org/wiki/Java_Native_Interface

but I got it from the book: Liang, Sheng (June 20, 1999). Java(TM) Native
Interface: Programmer's Guide and Specification (1st ed.). Prentice Hall. p.
320. ISBN 0-201-32577-2.

When I was faced with this issue, I ended up converting the strings to UTF-8 in
java, and then passing the result through the JNI as a byte array.