Do not use android specific API in mojo/java.

Do not use android specific API in mojo/java.

R=abarth@chromium.org, eseidel@chromium.org

Committed: https://chromium.googlesource.com/external/mojo/+/61c4870fa8e8d769f80d44c6bfe02940a9f8d759

[qsr, 2015-07-02 12:50:53]

Eric, this code is right now only used by Sky, so let it stay there.

 It has a couple of issues to be used more generally -> 1) naming, this is
android specific code, not java, so this cannot be used indifferently.

 Also, mojo android application cannot use Handler indifferently as most of
their threads are run from native, so this code will not work in those cases.

 If we need this for mojo android application, we can think at moving it back,
but until then, I'd rather not have it in //mojo.

[abarth-chromium, 2015-07-02 13:44:14]

abarth@chromium.org changed reviewers:
+ abarth@chromium.org

[abarth-chromium, 2015-07-02 13:44:15]

Instead, would it make sense to remove the Android / Handler dependency from
this code and leave it in a more general location?  We use the C++ and Dart
versions of DataPipeUtils constantly.  It seems very likely that many Java Mojo
apps will want to use this functionality.

[qsr, 2015-07-02 13:47:50]

On 2015/07/02 13:44:15, abarth-chromium wrote:
> Instead, would it make sense to remove the Android / Handler dependency from
> this code and leave it in a more general location?  We use the C++ and Dart
> versions of DataPipeUtils constantly.  It seems very likely that many Java
Mojo
> apps will want to use this functionality.

 We can use Core.getCurrentRunLoop() instead of the handler. But I do not know
enough about sky to know if it will work correctly in this context. If we do, we
can let this code in mojo/java (but we should still make a src dir in the java
directory so as not to have the Build.gn file at the same level as org/

[abarth-chromium, 2015-07-02 14:15:01]

On 2015/07/02 at 13:47:50, qsr wrote:
>  We can use Core.getCurrentRunLoop() instead of the handler. But I do not know
enough about sky to know if it will work correctly in this context.

This Java code is run on a thread that has an Android Looper and a
base::MessageLoop with TYPE_JAVA.  Can getCurrentRunLoop integrate with an
existing base::MessageLoop on a thread?  If so, it should work fine.

> If we do, we can let this code in mojo/java (but we should still make a src
dir in the java directory so as not to have the Build.gn file at the same level
as org/

Ok.  We seem to sometimes have a |src| directory and sometimes not have a |src|
directory.  It doesn't matter either way to me, but I'm curious what problem the
|src| directory solves.

[qsr, 2015-07-02 14:26:51]

On 2015/07/02 14:15:01, abarth-chromium wrote:
> On 2015/07/02 at 13:47:50, qsr wrote:
> >  We can use Core.getCurrentRunLoop() instead of the handler. But I do not
know
> enough about sky to know if it will work correctly in this context.
> 
> This Java code is run on a thread that has an Android Looper and a
> base::MessageLoop with TYPE_JAVA.  Can getCurrentRunLoop integrate with an
> existing base::MessageLoop on a thread?  If so, it should work fine.

 It does, so yes it should work fine.

> > If we do, we can let this code in mojo/java (but we should still make a src
> dir in the java directory so as not to have the Build.gn file at the same
level
> as org/
> 
> Ok.  We seem to sometimes have a |src| directory and sometimes not have a
|src|
> directory.  It doesn't matter either way to me, but I'm curious what problem
the
> |src| directory solves.

 It removes warnings with IDE that consider everything in a source folder to be
sources.

[abarth-chromium, 2015-07-02 14:36:27]

On 2015/07/02 at 14:26:51, qsr wrote:
> On 2015/07/02 14:15:01, abarth-chromium wrote:
> > On 2015/07/02 at 13:47:50, qsr wrote:
> > >  We can use Core.getCurrentRunLoop() instead of the handler. But I do not
know
> > enough about sky to know if it will work correctly in this context.
> > 
> > This Java code is run on a thread that has an Android Looper and a
> > base::MessageLoop with TYPE_JAVA.  Can getCurrentRunLoop integrate with an
> > existing base::MessageLoop on a thread?  If so, it should work fine.
> 
>  It does, so yes it should work fine.

Great!

> > > If we do, we can let this code in mojo/java (but we should still make a
src
> > dir in the java directory so as not to have the Build.gn file at the same
level
> > as org/
> > 
> > Ok.  We seem to sometimes have a |src| directory and sometimes not have a
|src|
> > directory.  It doesn't matter either way to me, but I'm curious what problem
the
> > |src| directory solves.
> 
>  It removes warnings with IDE that consider everything in a source folder to
be sources.

Makes sense.

[qsr, 2015-07-02 16:24:52]

Updated. Now in mojo/java but without android specific APIs.

[abarth-chromium, 2015-07-02 16:27:14]

lgtm

[eseidel1, 2015-07-03 00:43:57]

On 2015/07/02 at 16:27:14, abarth wrote:
> lgtm

Thanks!

[qsr, 2015-07-06 12:56:18]

Committed patchset #2 (id:20001) manually as
61c4870fa8e8d769f80d44c6bfe02940a9f8d759 (presubmit successful).