Java API for mojo system.

Java API for mojo system.

This CL introduce the java API for mojo system. It also introduces the android
implementation of this API.

Committed: https://src.chromium.org/viewvc/chrome?view=rev&revision=265658

[viettrungluu, 2014-04-08 22:35:19]

Thanks for working on this!

In general, it looks quite reasonable to me ... but I don't know Java. (So
probably someone else should also look at it.)

https://codereview.chromium.org/228723002/diff/20001/mojo/public/java/org/chr...
File mojo/public/java/org/chromium/mojo/system/Handle.java (right):

https://codereview.chromium.org/228723002/diff/20001/mojo/public/java/org/chr...
mojo/public/java/org/chromium/mojo/system/Handle.java:15: public static final
long DEADLINE_INFINITE = -1;
I think my preference would be to move this, WaitFlags, and wait() to Core.

Admittedly, it's also very natural to have wait() be a method on Handle, but I
prefer the parallelism of having wait and waitMany functions (in the same
place).

[qsr, 2014-04-14 11:59:43]

Updated the API, adding start implementation and unit test.

+bulach for java review

Comments are completely lacking, but would be a way to start the discussion for
tomorrow.

[qsr, 2014-04-14 12:03:05]

+ bulach for real this time.

[bulach, 2014-04-14 17:39:55]

uncomfortably exciting! :) mostly nits to get things cleared up, and some random
generic suggestions below...

https://codereview.chromium.org/228723002/diff/130001/build/android/pylib/con...
File build/android/pylib/constants.py (right):

https://codereview.chromium.org/228723002/diff/130001/build/android/pylib/con...
build/android/pylib/constants.py:136: ANDROID_SDK_VERSION = 18
is it intentional? :) if so, why?

https://codereview.chromium.org/228723002/diff/130001/mojo/public/java/src/or...
File mojo/public/java/src/org/chromium/mojo/system/Core.java (right):

https://codereview.chromium.org/228723002/diff/130001/mojo/public/java/src/or...
mojo/public/java/src/org/chromium/mojo/system/Core.java:43: public WaitFlags
readable(boolean readable) {
nit: I think it's more common to have "set/get" prefixes, so this would be
setReadable (and setWritable below)

https://codereview.chromium.org/228723002/diff/130001/mojo/public/java/src/or...
mojo/public/java/src/org/chromium/mojo/system/Core.java:68: return new
WaitFlags(FLAG_ALL);
what's the expected usage? in a tight loop, this would churn the heap.
patterns I've seen:
- return the int, so then callers would explicitly have to call the new, and
potentially unroll in their loops.
- have a static final object

https://codereview.chromium.org/228723002/diff/130001/mojo/public/java/src/or...
File mojo/public/java/src/org/chromium/mojo/system/DataPipe.java (right):

https://codereview.chromium.org/228723002/diff/130001/mojo/public/java/src/or...
mojo/public/java/src/org/chromium/mojo/system/DataPipe.java:55: public int
capacityNumBytes;
nit: we normally don't expose naked members.
alternatives:
- make them final, and have a ctor taking all of them.
- keep them private with getters / setters where needed.

https://codereview.chromium.org/228723002/diff/130001/mojo/public/java/src/or...
mojo/public/java/src/org/chromium/mojo/system/DataPipe.java:144: return new
ReadFlags(FLAG_NONE);
as above..

https://codereview.chromium.org/228723002/diff/130001/mojo/public/java/src/or...
mojo/public/java/src/org/chromium/mojo/system/DataPipe.java:169: public
java.nio.ByteBuffer beingWriteData(int numBytes, WriteFlags flags);
nit: just ByteBuffer, since it's already imported?

https://codereview.chromium.org/228723002/diff/130001/mojo/public/java/src/or...
mojo/public/java/src/org/chromium/mojo/system/DataPipe.java:199: public
java.nio.ByteBuffer beingReadData(int numBytes, ReadFlags flags);
nit: as above

https://codereview.chromium.org/228723002/diff/130001/mojo/public/java/src/or...
File mojo/public/java/src/org/chromium/mojo/system/Flags.java (right):

https://codereview.chromium.org/228723002/diff/130001/mojo/public/java/src/or...
mojo/public/java/src/org/chromium/mojo/system/Flags.java:21: this.mFlags =
flags;
nit: s/this.//

https://codereview.chromium.org/228723002/diff/130001/mojo/public/java/src/or...
File mojo/public/java/src/org/chromium/mojo/system/MojoResult.java (right):

https://codereview.chromium.org/228723002/diff/130001/mojo/public/java/src/or...
mojo/public/java/src/org/chromium/mojo/system/MojoResult.java:10: public enum
MojoResult {
enums are a no-go in java.. :(

https://codereview.chromium.org/228723002/diff/130001/mojo/public/java/src/or...
File mojo/public/java/src/org/chromium/mojo/system/Pair.java (right):

https://codereview.chromium.org/228723002/diff/130001/mojo/public/java/src/or...
mojo/public/java/src/org/chromium/mojo/system/Pair.java:10: * A pair of object.
how about just using android.util.Pair directly?

https://codereview.chromium.org/228723002/diff/130001/mojo/public/java/src/or...
File mojo/public/java/src/org/chromium/mojo/system/SharedBufferHandle.java
(right):

https://codereview.chromium.org/228723002/diff/130001/mojo/public/java/src/or...
mojo/public/java/src/org/chromium/mojo/system/SharedBufferHandle.java:42: public
CreateFlags flags;
ditto

https://codereview.chromium.org/228723002/diff/130001/mojo/system/android/cor...
File mojo/system/android/core_impl.cc (right):

https://codereview.chromium.org/228723002/diff/130001/mojo/system/android/cor...
mojo/system/android/core_impl.cc:32: DCHECK(buffer_start);
probably best as CHECK ?

https://codereview.chromium.org/228723002/diff/130001/mojo/system/android/cor...
mojo/system/android/core_impl.cc:38: const MojoHandle* handleStart =
nit: handle_start

https://codereview.chromium.org/228723002/diff/130001/mojo/system/android/cor...
mojo/system/android/core_impl.cc:46: MojoHandle handle1, handle2;
nit: one per line. also, perhaps input / output?

https://codereview.chromium.org/228723002/diff/130001/mojo/system/android/cor...
mojo/system/android/core_impl.cc:54: jobject optionsBuffer) {
nit: s/sBuffer/s_buffer/

https://codereview.chromium.org/228723002/diff/130001/mojo/system/android/cor...
mojo/system/android/core_impl.cc:60: DCHECK_EQ(buffer_size,
sizeof(MojoCreateDataPipeOptions));
CHECKs ?

https://codereview.chromium.org/228723002/diff/130001/mojo/system/android/cor...
mojo/system/android/core_impl.cc:73: jlong numBytes) {
nit: s/mBytes/m_bytes/, s/sBuffer/s_buffer/

https://codereview.chromium.org/228723002/diff/130001/mojo/system/android/cor...
mojo/system/android/core_impl.cc:140: buffer_size =
env->GetDirectBufferCapacity(bytes);
I'd create a simple java wrapper and use our own JNI..
I suppose some of these "env->" calls could throw exceptions that need to be
checked, etc..

if not a java wrapper, perhaps add in base/android/jni_direct_buffer.h ?

https://codereview.chromium.org/228723002/diff/130001/mojo/system/android/cor...
mojo/system/android/core_impl.cc:239: jint numBytesWritten) {
s/mBytesW/m_bytes_w/ (similarly for other parameters in the functions below..)

https://codereview.chromium.org/228723002/diff/130001/mojo/system/android/src...
File mojo/system/android/src/org/chromium/mojo/system/CoreImpl.java (right):

https://codereview.chromium.org/228723002/diff/130001/mojo/system/android/src...
mojo/system/android/src/org/chromium/mojo/system/CoreImpl.java:569: private
static class NativeCodeAndBufferResult {
nit: from here until 617, please move before the "private native" declarations..

[viettrungluu, 2014-04-14 18:02:49]

(Drive-by-ish comments.)

https://codereview.chromium.org/228723002/diff/130001/mojo/system/android/cor...
File mojo/system/android/core_impl.cc (right):

https://codereview.chromium.org/228723002/diff/130001/mojo/system/android/cor...
mojo/system/android/core_impl.cc:39: reinterpret_cast<const
MojoHandle*>(buffer_start);
nit (here and everywhere else): (const) void* -> (const) Foo* only requires a
static_cast, not a reinterpret_cast.

https://codereview.chromium.org/228723002/diff/130001/mojo/system/android/cor...
mojo/system/android/core_impl.cc:60: DCHECK_EQ(buffer_size,
sizeof(MojoCreateDataPipeOptions));
Note that the various Mojo...Options structures are designed to be extensible,
so you probably shouldn't bother checking very much at this layer.

https://codereview.chromium.org/228723002/diff/130001/mojo/system/android/cor...
mojo/system/android/core_impl.cc:62: DCHECK_EQ(options->struct_size,
buffer_size);
Depending on the amount of safety we want to enforce, the correct check might be
to check that |buffer_size >= sizeof(uint32_t) && options->struct_size <=
buffer_size|, and throw MOJO_RESULT_INVALID_ARGUMENT if not.

[viettrungluu, 2014-04-14 18:15:55]

Also, mojo/system/android/ is probably not quite the correct location for the
stuff you added under there. (In particular, the stuff in there doesn't[*]
include anything in mojo/system/.

We haven't been especially coherent in organizing stuff under mojo/ outside of
mojo/public/ (or, rather, we haven't reorganized it yet).

Maybe the right place would be simply mojo/android/(system/) or something like
that instead. Then the gles2 support would presumably go under
mojo/android/gles2/, etc.

(Though maybe "android" isn't a sufficiently complete qualifier, since this is
really "Java on android".)

[*] And this is as it should be.

[qsr, 2014-04-15 08:37:27]

On 2014/04/14 18:15:55, viettrungluu wrote:
> Also, mojo/system/android/ is probably not quite the correct location for the
> stuff you added under there. (In particular, the stuff in there doesn't[*]
> include anything in mojo/system/.
> 
> We haven't been especially coherent in organizing stuff under mojo/ outside of
> mojo/public/ (or, rather, we haven't reorganized it yet).
> 
> Maybe the right place would be simply mojo/android/(system/) or something like
> that instead. Then the gles2 support would presumably go under
> mojo/android/gles2/, etc.
> 
> (Though maybe "android" isn't a sufficiently complete qualifier, since this is
> really "Java on android".)

 Would something like:

mojo/android/gles2
mojo/android/java/system

be fine with you ?

> [*] And this is as it should be.

[qsr, 2014-04-15 08:37:36]

https://chromiumcodereview.appspot.com/228723002/diff/130001/build/android/py...
File build/android/pylib/constants.py (right):

https://chromiumcodereview.appspot.com/228723002/diff/130001/build/android/py...
build/android/pylib/constants.py:136: ANDROID_SDK_VERSION = 18
On 2014/04/14 17:39:56, bulach wrote:
> is it intentional? :) if so, why?

 So, it should not be in the review, but I had to change this because I had a
problem with the dex merger that was throwing a NPE. Seems to have solved itself
since then.

https://chromiumcodereview.appspot.com/228723002/diff/130001/mojo/public/java...
File mojo/public/java/src/org/chromium/mojo/system/Core.java (right):

https://chromiumcodereview.appspot.com/228723002/diff/130001/mojo/public/java...
mojo/public/java/src/org/chromium/mojo/system/Core.java:43: public WaitFlags
readable(boolean readable) {
On 2014/04/14 17:39:56, bulach wrote:
> nit: I think it's more common to have "set/get" prefixes, so this would be
> setReadable (and setWritable below)

 The thing is this is more a builder than a simple class, that's why I choose
this. The idea is that you can put those one after the other to set multiple
flags. If you feel strongly about this, I can change it, but that would be
weirder to use:

I prefer:
Flags.none().readable(true).writable(true)
to:
Flags.none().setReadable(true).setWritable(true)

https://chromiumcodereview.appspot.com/228723002/diff/130001/mojo/public/java...
mojo/public/java/src/org/chromium/mojo/system/Core.java:68: return new
WaitFlags(FLAG_ALL);
On 2014/04/14 17:39:56, bulach wrote:
> what's the expected usage? in a tight loop, this would churn the heap.
> patterns I've seen:

 Are you speaking about this method in general or flags in general?

> - return the int, so then callers would explicitly have to call the new, and
> potentially unroll in their loops.

 Those flags are for IO methods, I do not see those used in tight loop. Also, I
do not want to expose a constructor with an int, as it allows for wrong values.

> - have a static final object

 The flags are mutable, final being what it is in java, I cannot do that.

https://chromiumcodereview.appspot.com/228723002/diff/130001/mojo/public/java...
File mojo/public/java/src/org/chromium/mojo/system/DataPipe.java (right):

https://chromiumcodereview.appspot.com/228723002/diff/130001/mojo/public/java...
mojo/public/java/src/org/chromium/mojo/system/DataPipe.java:55: public int
capacityNumBytes;
On 2014/04/14 17:39:56, bulach wrote:
> nit: we normally don't expose naked members.
> alternatives:
> - make them final, and have a ctor taking all of them.
> - keep them private with getters / setters where needed.

 I cannot do the first. This is an API. I want use to be able to update the
version of the API without having to modify their code if possible, having a
ctor will force to change all callers. Getter/Setter is possible if we really do
not want the naked field, but make the declaration and usage very verbose for
something that is really just a plain data container... Also, I didn't find
anything in either google or a android style guide against it.

https://chromiumcodereview.appspot.com/228723002/diff/130001/mojo/public/java...
mojo/public/java/src/org/chromium/mojo/system/DataPipe.java:144: return new
ReadFlags(FLAG_NONE);
On 2014/04/14 17:39:56, bulach wrote:
> as above..

 So I guess the issue was not with all(), but with flags in general.

 I wrote those flags because I wanted the API to be clear about what flag it
expected. Unfortunately java doesn't have anything that looks like typedef, so
if I want to have something clear, I need to use class and not int.

 I do not think this is really an issue as all those flags are used for I/O, so
the creation of an object should not be relevant performance wise. Now if you
have any idea on how to do something better, I'm all for it, but I'd really like
the solution to have an API that specify exactly what you should put in it.

https://chromiumcodereview.appspot.com/228723002/diff/130001/mojo/public/java...
mojo/public/java/src/org/chromium/mojo/system/DataPipe.java:169: public
java.nio.ByteBuffer beingWriteData(int numBytes, WriteFlags flags);
On 2014/04/14 17:39:56, bulach wrote:
> nit: just ByteBuffer, since it's already imported?

Done.

https://chromiumcodereview.appspot.com/228723002/diff/130001/mojo/public/java...
mojo/public/java/src/org/chromium/mojo/system/DataPipe.java:199: public
java.nio.ByteBuffer beingReadData(int numBytes, ReadFlags flags);
On 2014/04/14 17:39:56, bulach wrote:
> nit: as above

Done.

https://chromiumcodereview.appspot.com/228723002/diff/130001/mojo/public/java...
File mojo/public/java/src/org/chromium/mojo/system/Flags.java (right):

https://chromiumcodereview.appspot.com/228723002/diff/130001/mojo/public/java...
mojo/public/java/src/org/chromium/mojo/system/Flags.java:21: this.mFlags =
flags;
On 2014/04/14 17:39:56, bulach wrote:
> nit: s/this.//

Done.

https://chromiumcodereview.appspot.com/228723002/diff/130001/mojo/public/java...
File mojo/public/java/src/org/chromium/mojo/system/MojoResult.java (right):

https://chromiumcodereview.appspot.com/228723002/diff/130001/mojo/public/java...
mojo/public/java/src/org/chromium/mojo/system/MojoResult.java:10: public enum
MojoResult {
On 2014/04/14 17:39:56, bulach wrote:
> enums are a no-go in java.. :(

 Not sure to understand. We are still supporting java4? Why?

 Also, in chromium/src

$ git grep '\(\(public\)\|\(private\)\) enum' -- \*.java | wc -l
17

https://chromiumcodereview.appspot.com/228723002/diff/130001/mojo/public/java...
File mojo/public/java/src/org/chromium/mojo/system/Pair.java (right):

https://chromiumcodereview.appspot.com/228723002/diff/130001/mojo/public/java...
mojo/public/java/src/org/chromium/mojo/system/Pair.java:10: * A pair of object.
On 2014/04/14 17:39:56, bulach wrote:
> how about just using android.util.Pair directly?

 This part is a public sdk, not necessary targeted to android. See:
https://groups.google.com/a/chromium.org/forum/#!topic/mojo-dev/1SXfR-78ypM

https://chromiumcodereview.appspot.com/228723002/diff/130001/mojo/system/andr...
File mojo/system/android/core_impl.cc (right):

https://chromiumcodereview.appspot.com/228723002/diff/130001/mojo/system/andr...
mojo/system/android/core_impl.cc:32: DCHECK(buffer_start);
On 2014/04/14 17:39:56, bulach wrote:
> probably best as CHECK ?

 We do create and provide this buffer in java world. Do we really want to check
this in release mode?

https://chromiumcodereview.appspot.com/228723002/diff/130001/mojo/system/andr...
mojo/system/android/core_impl.cc:38: const MojoHandle* handleStart =
On 2014/04/14 17:39:56, bulach wrote:
> nit: handle_start

Done.

https://chromiumcodereview.appspot.com/228723002/diff/130001/mojo/system/andr...
mojo/system/android/core_impl.cc:39: reinterpret_cast<const
MojoHandle*>(buffer_start);
On 2014/04/14 18:02:50, viettrungluu wrote:
> nit (here and everywhere else): (const) void* -> (const) Foo* only requires a
> static_cast, not a reinterpret_cast.

Done.

https://chromiumcodereview.appspot.com/228723002/diff/130001/mojo/system/andr...
mojo/system/android/core_impl.cc:46: MojoHandle handle1, handle2;
On 2014/04/14 17:39:56, bulach wrote:
> nit: one per line. also, perhaps input / output?

 message pipe are bidi, there is no input output here.

https://chromiumcodereview.appspot.com/228723002/diff/130001/mojo/system/andr...
mojo/system/android/core_impl.cc:54: jobject optionsBuffer) {
On 2014/04/14 17:39:56, bulach wrote:
> nit: s/sBuffer/s_buffer/

Done.

https://chromiumcodereview.appspot.com/228723002/diff/130001/mojo/system/andr...
mojo/system/android/core_impl.cc:60: DCHECK_EQ(buffer_size,
sizeof(MojoCreateDataPipeOptions));
On 2014/04/14 18:02:50, viettrungluu wrote:
> Note that the various Mojo...Options structures are designed to be extensible,
> so you probably shouldn't bother checking very much at this layer.

 Well, they are extensible in a C++ word, where the system is an independent
library. In the java world this file lives in, this code is tightly tide to the
java code, and so this should have been compiled at the same time as the java
library. The java library is the one that define the java option class, and that
translate that into the struct it knows about. So there is no extension
possible, and the advantage to have those checks here is that it will force us
to update the java option class and the translation if new options appear.
Unless you have a strong case not wanting this, I think we are better with all
those checks.

https://chromiumcodereview.appspot.com/228723002/diff/130001/mojo/system/andr...
mojo/system/android/core_impl.cc:60: DCHECK_EQ(buffer_size,
sizeof(MojoCreateDataPipeOptions));
On 2014/04/14 17:39:56, bulach wrote:
> CHECKs ?

 Same as above. This is completely on our control. Test should be enough to
catch problems.

https://chromiumcodereview.appspot.com/228723002/diff/130001/mojo/system/andr...
mojo/system/android/core_impl.cc:62: DCHECK_EQ(options->struct_size,
buffer_size);
On 2014/04/14 18:02:50, viettrungluu wrote:
> Depending on the amount of safety we want to enforce, the correct check might
be
> to check that |buffer_size >= sizeof(uint32_t) && options->struct_size <=
> buffer_size|, and throw MOJO_RESULT_INVALID_ARGUMENT if not.

 The buffer creation is done in the java code, translated from a java class. The
user has no control over it at all, so I think DCHECK is the right primitive. If
something is wrong at this level, the error if from us, not from the user of the
library.

https://chromiumcodereview.appspot.com/228723002/diff/130001/mojo/system/andr...
mojo/system/android/core_impl.cc:73: jlong numBytes) {
On 2014/04/14 17:39:56, bulach wrote:
> nit: s/mBytes/m_bytes/, s/sBuffer/s_buffer/

Done.

https://chromiumcodereview.appspot.com/228723002/diff/130001/mojo/system/andr...
mojo/system/android/core_impl.cc:140: buffer_size =
env->GetDirectBufferCapacity(bytes);
On 2014/04/14 17:39:56, bulach wrote:
> I'd create a simple java wrapper and use our own JNI..
> I suppose some of these "env->" calls could throw exceptions that need to be
> checked, etc..
> 
> if not a java wrapper, perhaps add in base/android/jni_direct_buffer.h ?

 I'm sorry, but I do not understand what you mean. Those methods are not
throwing exceptions. The only one that can, is the NewDirectBuffer, but it can
only throw OOM, and we do not want to catch this one.

 Also, we are already using those methods in the code base.

https://chromiumcodereview.appspot.com/228723002/diff/130001/mojo/system/andr...
mojo/system/android/core_impl.cc:239: jint numBytesWritten) {
On 2014/04/14 17:39:56, bulach wrote:
> s/mBytesW/m_bytes_w/ (similarly for other parameters in the functions below..)

Done.

https://chromiumcodereview.appspot.com/228723002/diff/130001/mojo/system/andr...
File mojo/system/android/src/org/chromium/mojo/system/CoreImpl.java (right):

https://chromiumcodereview.appspot.com/228723002/diff/130001/mojo/system/andr...
mojo/system/android/src/org/chromium/mojo/system/CoreImpl.java:569: private
static class NativeCodeAndBufferResult {
On 2014/04/14 17:39:56, bulach wrote:
> nit: from here until 617, please move before the "private native"
declarations..

Done.

[viettrungluu, 2014-04-15 16:54:30]

On 2014/04/15 08:37:36, qsr wrote:
>
https://chromiumcodereview.appspot.com/228723002/diff/130001/mojo/system/andr...
> mojo/system/android/core_impl.cc:60: DCHECK_EQ(buffer_size,
> sizeof(MojoCreateDataPipeOptions));
> On 2014/04/14 18:02:50, viettrungluu wrote:
> > Note that the various Mojo...Options structures are designed to be
extensible,
> > so you probably shouldn't bother checking very much at this layer.
> 
>  Well, they are extensible in a C++ word, where the system is an independent
> library. In the java world this file lives in, this code is tightly tide to
the
> java code, and so this should have been compiled at the same time as the java
> library. The java library is the one that define the java option class, and
that
> translate that into the struct it knows about. So there is no extension
> possible, and the advantage to have those checks here is that it will force us
> to update the java option class and the translation if new options appear.
> Unless you have a strong case not wanting this, I think we are better with all
> those checks.

So I'm okay with this, but I'd like to clarify some things (about Java):
- I assume that the org.chromium.mojo.system package would be bundled with the
browser/system/host/whatever, right? (As opposed to being part of the
application code.)
- If the org.chromium.mojo.system package is updated -- say something is added
to DataPipe.CreateOptions -- would people who wrote/built their apps against the
older version need to rebuild their apps? (My guess is no, since people don't
need to rebuild their apps against every new Android release for example, but I
don't know anything.)

[qsr, 2014-04-16 07:49:51]

On 2014/04/15 16:54:30, viettrungluu wrote:
> On 2014/04/15 08:37:36, qsr wrote:
> >
>
https://chromiumcodereview.appspot.com/228723002/diff/130001/mojo/system/andr...
> > mojo/system/android/core_impl.cc:60: DCHECK_EQ(buffer_size,
> > sizeof(MojoCreateDataPipeOptions));
> > On 2014/04/14 18:02:50, viettrungluu wrote:
> > > Note that the various Mojo...Options structures are designed to be
> extensible,
> > > so you probably shouldn't bother checking very much at this layer.
> > 
> >  Well, they are extensible in a C++ word, where the system is an independent
> > library. In the java world this file lives in, this code is tightly tide to
> the
> > java code, and so this should have been compiled at the same time as the
java
> > library. The java library is the one that define the java option class, and
> that
> > translate that into the struct it knows about. So there is no extension
> > possible, and the advantage to have those checks here is that it will force
us
> > to update the java option class and the translation if new options appear.
> > Unless you have a strong case not wanting this, I think we are better with
all
> > those checks.
> 
> So I'm okay with this, but I'd like to clarify some things (about Java):
> - I assume that the org.chromium.mojo.system package would be bundled with the
> browser/system/host/whatever, right? (As opposed to being part of the
> application code.)

 Yes. The application will write against the SDK, but won't ship it. The browser
will contain the SDK and its implementation.

> - If the org.chromium.mojo.system package is updated -- say something is added
> to DataPipe.CreateOptions -- would people who wrote/built their apps against
the
> older version need to rebuild their apps? (My guess is no, since people don't
> need to rebuild their apps against every new Android release for example, but
I
> don't know anything.)

 The answer is no if we do our job correctly. What I mean is that if the methods
and class the application is using still exist after the upgrade, no
re-compilation is needed. I designed the API so that we can add content to
options and flags without changing any existing method exactly for this case.

 PS: Did you see my suggestion just before for hierarchy: 

mojo/android/gles2
mojo/android/java/system

 Is that fine with you?

[qsr, 2014-04-16 13:41:43]

Ok, this is now ready for review.

 Marcus -> Changed the enum to an int, added getter and setter everywhere I was
using naked members.

 viettrungluu -> Will move this to the right place if you agree with my
proposition, or any other place if you have a better idea.

[koz (OOO until 15th September), 2014-04-16 20:57:03]

Drive by.

https://codereview.chromium.org/228723002/diff/190001/mojo/public/java/src/or...
File mojo/public/java/src/org/chromium/mojo/system/MessagePipeHandle.java
(right):

https://codereview.chromium.org/228723002/diff/190001/mojo/public/java/src/or...
mojo/public/java/src/org/chromium/mojo/system/MessagePipeHandle.java:78: * count
|num_handles|, and options specified by |flags|. If there is no message data,
|bytes|
|num_handles| no longer exists as a parameter.

https://codereview.chromium.org/228723002/diff/190001/mojo/system/android/src...
File mojo/system/android/src/org/chromium/mojo/system/CoreImpl.java (right):

https://codereview.chromium.org/228723002/diff/190001/mojo/system/android/src...
mojo/system/android/src/org/chromium/mojo/system/CoreImpl.java:57: private
static int waitMojoResultToBoolean(int code) {
Should this be called waitResultToMojoResult()?

[qsr, 2014-04-17 08:17:31]

https://chromiumcodereview.appspot.com/228723002/diff/190001/mojo/public/java...
File mojo/public/java/src/org/chromium/mojo/system/MessagePipeHandle.java
(right):

https://chromiumcodereview.appspot.com/228723002/diff/190001/mojo/public/java...
mojo/public/java/src/org/chromium/mojo/system/MessagePipeHandle.java:78: * count
|num_handles|, and options specified by |flags|. If there is no message data,
|bytes|
On 2014/04/16 20:57:03, koz wrote:
> |num_handles| no longer exists as a parameter.

 Done, this comment was completely wrong from start to end, thanks for catching
it.

https://chromiumcodereview.appspot.com/228723002/diff/190001/mojo/system/andr...
File mojo/system/android/src/org/chromium/mojo/system/CoreImpl.java (right):

https://chromiumcodereview.appspot.com/228723002/diff/190001/mojo/system/andr...
mojo/system/android/src/org/chromium/mojo/system/CoreImpl.java:57: private
static int waitMojoResultToBoolean(int code) {
On 2014/04/16 20:57:03, koz wrote:
> Should this be called waitResultToMojoResult()?

 Thanks for the catch. Renamed to int filterMojoResultForWait(int code).

[bulach, 2014-04-17 13:15:42]

I'm not an owner here, so I'll leave for mojo'ers :)
this all seems fine by me, I just have a few more small suggestions, and one
question for viettrungluu below.
thanks, ben!

https://codereview.chromium.org/228723002/diff/210001/build/common.gypi
File build/common.gypi (right):

https://codereview.chromium.org/228723002/diff/210001/build/common.gypi#newco...
build/common.gypi:1517: 'android_sdk_build_tools_version%': '18.0.1',
nit: left over? :)

https://codereview.chromium.org/228723002/diff/210001/mojo/public/java/src/or...
File mojo/public/java/src/org/chromium/mojo/system/Core.java (right):

https://codereview.chromium.org/228723002/diff/210001/mojo/public/java/src/or...
mojo/public/java/src/org/chromium/mojo/system/Core.java:33: private static final
int FLAG_NONE = 0;
nit: it'd be nice to share these flags with the native side using the template
mechanisms, similar to:
https://code.google.com/p/chromium/codesearch#chromium/src/net/base/net_error...

https://codereview.chromium.org/228723002/diff/210001/mojo/public/java/src/or...
mojo/public/java/src/org/chromium/mojo/system/Core.java:44: public WaitFlags
readable(boolean readable) {
nit: should this be a setReadable / setWritable below?

https://codereview.chromium.org/228723002/diff/210001/mojo/public/java/src/or...
File mojo/public/java/src/org/chromium/mojo/system/DataPipe.java (right):

https://codereview.chromium.org/228723002/diff/210001/mojo/public/java/src/or...
mojo/public/java/src/org/chromium/mojo/system/DataPipe.java:21: private static
final int FLAG_MAY_DISCARD = 1 << 0;
nit: ditto for these flags..

https://codereview.chromium.org/228723002/diff/210001/mojo/public/java/src/or...
mojo/public/java/src/org/chromium/mojo/system/DataPipe.java:198: public static
interface ProducerHandle extends Handle {
these Producer|ConsumerHandle interfaces look fairly independent on DataPipe,
they only need their respective Write/Read flags. perhaps split into their own
files?
something like:
- DataPipeProducer.java: contains Handle / Flags classes.
- DataPipeConsumer.java: similarly.

https://codereview.chromium.org/228723002/diff/210001/mojo/public/java/src/or...
File mojo/public/java/src/org/chromium/mojo/system/MessagePipeHandle.java
(right):

https://codereview.chromium.org/228723002/diff/210001/mojo/public/java/src/or...
mojo/public/java/src/org/chromium/mojo/system/MessagePipeHandle.java:113: public
boolean getWasMessageRead() {
nit: looks like the class is package-private. can these methods be as well?

https://codereview.chromium.org/228723002/diff/210001/mojo/public/java/src/or...
File mojo/public/java/src/org/chromium/mojo/system/MojoException.java (right):

https://codereview.chromium.org/228723002/diff/210001/mojo/public/java/src/or...
mojo/public/java/src/org/chromium/mojo/system/MojoException.java:12: private int
mCode;
nit: final

https://codereview.chromium.org/228723002/diff/210001/mojo/public/java/src/or...
File mojo/public/java/src/org/chromium/mojo/system/MojoResult.java (right):

https://codereview.chromium.org/228723002/diff/210001/mojo/public/java/src/or...
mojo/public/java/src/org/chromium/mojo/system/MojoResult.java:11: public static
final int OK = 0;
nit: ditto

https://codereview.chromium.org/228723002/diff/210001/mojo/public/java/src/or...
File mojo/public/java/src/org/chromium/mojo/system/Pair.java (right):

https://codereview.chromium.org/228723002/diff/210001/mojo/public/java/src/or...
mojo/public/java/src/org/chromium/mojo/system/Pair.java:15: public class Pair<F,
S> {
@viettrungluu: could we discuss about the ultimate goals for mojo? :)
qsr said that ultimately we want to be run-time independent.
it seems a bit of an overkill, since android does provide a "Pair" class.. are
we planning to run this on any other run time?

I mean, it'd be nice to have and all that :) but objectively, saving binary size
is a big goal for chrome on android: if we could save now in exchange for a
future possibility of using other runtimes, I'd suggest choosing to save
precious bytes now... wdyt?

https://codereview.chromium.org/228723002/diff/210001/mojo/system/android/cor...
File mojo/system/android/core_impl.cc (right):

https://codereview.chromium.org/228723002/diff/210001/mojo/system/android/cor...
mojo/system/android/core_impl.cc:40: const MojoWaitFlags* flagsStart =
nit: flag_start

https://codereview.chromium.org/228723002/diff/210001/mojo/system/android/jav...
File mojo/system/android/javatests/core_test.cc (right):

https://codereview.chromium.org/228723002/diff/210001/mojo/system/android/jav...
mojo/system/android/javatests/core_test.cc:18: env, env->NewLocalRef(context));
nit: I suppose just context, without NewLocalRef, should be enough.

https://codereview.chromium.org/228723002/diff/210001/mojo/system/android/jav...
File mojo/system/android/javatests/src/org/chromium/mojo/system/CoreTest.java
(right):

https://codereview.chromium.org/228723002/diff/210001/mojo/system/android/jav...
mojo/system/android/javatests/src/org/chromium/mojo/system/CoreTest.java:45:
nativeInitApplicationContext(getInstrumentation().getContext());
nit: s/getContext/getTargetContext/

https://codereview.chromium.org/228723002/diff/210001/mojo/system/android/src...
File mojo/system/android/src/org/chromium/mojo/system/CoreImpl.java (right):

https://codereview.chromium.org/228723002/diff/210001/mojo/system/android/src...
mojo/system/android/src/org/chromium/mojo/system/CoreImpl.java:23: public class
CoreImpl implements Core {
nit: can these impl classes be package-private?

https://codereview.chromium.org/228723002/diff/210001/mojo/system/android/src...
mojo/system/android/src/org/chromium/mojo/system/CoreImpl.java:68:
buffer.putInt(4 * index, realHandler.getMojoHandle());
nit: there's a lot of "* 4" in this file... perhaps extract this into a static
final int HANDLE_SIZE = 4 ?

...should it ever grow... :)

[qsr, 2014-04-17 13:50:23]

https://codereview.chromium.org/228723002/diff/210001/build/common.gypi
File build/common.gypi (right):

https://codereview.chromium.org/228723002/diff/210001/build/common.gypi#newco...
build/common.gypi:1517: 'android_sdk_build_tools_version%': '18.0.1',
On 2014/04/17 13:15:42, bulach wrote:
> nit: left over? :)

Done.

https://codereview.chromium.org/228723002/diff/210001/mojo/public/java/src/or...
File mojo/public/java/src/org/chromium/mojo/system/Core.java (right):

https://codereview.chromium.org/228723002/diff/210001/mojo/public/java/src/or...
mojo/public/java/src/org/chromium/mojo/system/Core.java:33: private static final
int FLAG_NONE = 0;
On 2014/04/17 13:15:42, bulach wrote:
> nit: it'd be nice to share these flags with the native side using the template
> mechanisms, similar to:
>
https://code.google.com/p/chromium/codesearch#chromium/src/net/base/net_error...

 @viettrungluu what do you think? Do we want to do something like this?

 @bulach -> Are we agreeing that this can be submitted, and then evolve if we
add this kind of mechanism?

https://codereview.chromium.org/228723002/diff/210001/mojo/public/java/src/or...
mojo/public/java/src/org/chromium/mojo/system/Core.java:44: public WaitFlags
readable(boolean readable) {
On 2014/04/17 13:15:42, bulach wrote:
> nit: should this be a setReadable / setWritable below?

 Done. (I have answered on this on your previous comments, but you didn't
respond, so I guessed your were fine for flags. My argument was that this is
more a builder than an POJO, and I founded doing:

Flags.none().readable(true).foo(true).bar(true) was nicer than:
Flags.none().setReadable(true).setFoo(true).setBar(true)

https://codereview.chromium.org/228723002/diff/210001/mojo/public/java/src/or...
File mojo/public/java/src/org/chromium/mojo/system/DataPipe.java (right):

https://codereview.chromium.org/228723002/diff/210001/mojo/public/java/src/or...
mojo/public/java/src/org/chromium/mojo/system/DataPipe.java:198: public static
interface ProducerHandle extends Handle {
On 2014/04/17 13:15:42, bulach wrote:
> these Producer|ConsumerHandle interfaces look fairly independent on DataPipe,
> they only need their respective Write/Read flags. perhaps split into their own
> files?
> something like:
> - DataPipeProducer.java: contains Handle / Flags classes.
> - DataPipeConsumer.java: similarly.

 They are the two sides of a channel. I find it nicer to have this in a single
interface, as a namespace. Do you feel strongly about splitting this in 2 files?

https://codereview.chromium.org/228723002/diff/210001/mojo/public/java/src/or...
File mojo/public/java/src/org/chromium/mojo/system/MessagePipeHandle.java
(right):

https://codereview.chromium.org/228723002/diff/210001/mojo/public/java/src/or...
mojo/public/java/src/org/chromium/mojo/system/MessagePipeHandle.java:113: public
boolean getWasMessageRead() {
On 2014/04/17 13:15:42, bulach wrote:
> nit: looks like the class is package-private. can these methods be as well?

 Theer error was to have the class package private, this is part of the API, and
should be public, thanks for catching it.

https://codereview.chromium.org/228723002/diff/210001/mojo/public/java/src/or...
File mojo/public/java/src/org/chromium/mojo/system/MojoException.java (right):

https://codereview.chromium.org/228723002/diff/210001/mojo/public/java/src/or...
mojo/public/java/src/org/chromium/mojo/system/MojoException.java:12: private int
mCode;
On 2014/04/17 13:15:42, bulach wrote:
> nit: final

Done.

https://codereview.chromium.org/228723002/diff/210001/mojo/system/android/cor...
File mojo/system/android/core_impl.cc (right):

https://codereview.chromium.org/228723002/diff/210001/mojo/system/android/cor...
mojo/system/android/core_impl.cc:40: const MojoWaitFlags* flagsStart =
On 2014/04/17 13:15:42, bulach wrote:
> nit: flag_start

Done.

https://codereview.chromium.org/228723002/diff/210001/mojo/system/android/jav...
File mojo/system/android/javatests/core_test.cc (right):

https://codereview.chromium.org/228723002/diff/210001/mojo/system/android/jav...
mojo/system/android/javatests/core_test.cc:18: env, env->NewLocalRef(context));
On 2014/04/17 13:15:42, bulach wrote:
> nit: I suppose just context, without NewLocalRef, should be enough.

Done.

https://codereview.chromium.org/228723002/diff/210001/mojo/system/android/jav...
File mojo/system/android/javatests/src/org/chromium/mojo/system/CoreTest.java
(right):

https://codereview.chromium.org/228723002/diff/210001/mojo/system/android/jav...
mojo/system/android/javatests/src/org/chromium/mojo/system/CoreTest.java:45:
nativeInitApplicationContext(getInstrumentation().getContext());
On 2014/04/17 13:15:42, bulach wrote:
> nit: s/getContext/getTargetContext/

 Done, but this is the same thing. The APK is instrumenting itself.

https://codereview.chromium.org/228723002/diff/210001/mojo/system/android/src...
File mojo/system/android/src/org/chromium/mojo/system/CoreImpl.java (right):

https://codereview.chromium.org/228723002/diff/210001/mojo/system/android/src...
mojo/system/android/src/org/chromium/mojo/system/CoreImpl.java:23: public class
CoreImpl implements Core {
On 2014/04/17 13:15:42, bulach wrote:
> nit: can these impl classes be package-private?

 Most of those can, this one can't. We need to get the singleton. And probably
from other place than here.

https://codereview.chromium.org/228723002/diff/210001/mojo/system/android/src...
mojo/system/android/src/org/chromium/mojo/system/CoreImpl.java:68:
buffer.putInt(4 * index, realHandler.getMojoHandle());
On 2014/04/17 13:15:42, bulach wrote:
> nit: there's a lot of "* 4" in this file... perhaps extract this into a static
> final int HANDLE_SIZE = 4 ?
> 
> ...should it ever grow... :)

 Done, but I really do not see it growing anytime soon. Will break every
messages. Moreover, not all 4s are handle size, some are flag size. But I will
extract both.

[bulach, 2014-04-17 14:04:50]

thanks ben! some clarifications inline:

https://codereview.chromium.org/228723002/diff/210001/mojo/public/java/src/or...
File mojo/public/java/src/org/chromium/mojo/system/Core.java (right):

https://codereview.chromium.org/228723002/diff/210001/mojo/public/java/src/or...
mojo/public/java/src/org/chromium/mojo/system/Core.java:33: private static final
int FLAG_NONE = 0;
On 2014/04/17 13:50:24, qsr wrote:
> On 2014/04/17 13:15:42, bulach wrote:
> > nit: it'd be nice to share these flags with the native side using the
template
> > mechanisms, similar to:
> >
>
https://code.google.com/p/chromium/codesearch#chromium/src/net/base/net_error...
> 
>  @viettrungluu what do you think? Do we want to do something like this?
> 
>  @bulach -> Are we agreeing that this can be submitted, and then evolve if we
> add this kind of mechanism?

I don't care much about the order of patches, but would strongly suggest that
the end goal should reuse / share the values across java and c++: we're using
the template mechanism mentioned above in various other places and it the long
run it makes life much easier...

if you want to do as a follow up, or if you prefer to extract from the current
mojo system before this patch, I'll leave it to you.. :)

and to be clear: I would not suggest to do it as part of this patch..

https://codereview.chromium.org/228723002/diff/210001/mojo/public/java/src/or...
mojo/public/java/src/org/chromium/mojo/system/Core.java:44: public WaitFlags
readable(boolean readable) {
On 2014/04/17 13:50:24, qsr wrote:
> On 2014/04/17 13:15:42, bulach wrote:
> > nit: should this be a setReadable / setWritable below?
> 
>  Done. (I have answered on this on your previous comments, but you didn't
> respond, so I guessed your were fine for flags. My argument was that this is
> more a builder than an POJO, and I founded doing:
> 
> Flags.none().readable(true).foo(true).bar(true) was nicer than:
> Flags.none().setReadable(true).setFoo(true).setBar(true)

sorry, I thought on our meeting I said to keep similar to other "data holders"
like protobuf, which I think have setters... anyways, thanks for doing this!

https://codereview.chromium.org/228723002/diff/210001/mojo/system/android/src...
File mojo/system/android/src/org/chromium/mojo/system/CoreImpl.java (right):

https://codereview.chromium.org/228723002/diff/210001/mojo/system/android/src...
mojo/system/android/src/org/chromium/mojo/system/CoreImpl.java:23: public class
CoreImpl implements Core {
On 2014/04/17 13:50:24, qsr wrote:
> On 2014/04/17 13:15:42, bulach wrote:
> > nit: can these impl classes be package-private?
> 
>  Most of those can, this one can't. We need to get the singleton. And probably
> from other place than here.

looks like the getInstance() is only called on tests for now, and hopefully
won't be used outside this package in the future, right?
probably best to keep it package-private for now, and make it public later on if
needed, and even then, it'd probably be nicer to expose a separate class
returning the getInstance() as a Core rather than a CoreImpl...

[qsr, 2014-04-17 14:26:45]

On 2014/04/17 14:04:50, bulach wrote:
> thanks ben! some clarifications inline:
> 
>
https://codereview.chromium.org/228723002/diff/210001/mojo/public/java/src/or...
> File mojo/public/java/src/org/chromium/mojo/system/Core.java (right):
> 
>
https://codereview.chromium.org/228723002/diff/210001/mojo/public/java/src/or...
> mojo/public/java/src/org/chromium/mojo/system/Core.java:33: private static
final
> int FLAG_NONE = 0;
> On 2014/04/17 13:50:24, qsr wrote:
> > On 2014/04/17 13:15:42, bulach wrote:
> > > nit: it'd be nice to share these flags with the native side using the
> template
> > > mechanisms, similar to:
> > >
> >
>
https://code.google.com/p/chromium/codesearch#chromium/src/net/base/net_error...
> > 
> >  @viettrungluu what do you think? Do we want to do something like this?
> > 
> >  @bulach -> Are we agreeing that this can be submitted, and then evolve if
we
> > add this kind of mechanism?
> 
> I don't care much about the order of patches, but would strongly suggest that
> the end goal should reuse / share the values across java and c++: we're using
> the template mechanism mentioned above in various other places and it the long
> run it makes life much easier...
> 
> if you want to do as a follow up, or if you prefer to extract from the current
> mojo system before this patch, I'll leave it to you.. :)
> 
> and to be clear: I would not suggest to do it as part of this patch..
> 
>
https://codereview.chromium.org/228723002/diff/210001/mojo/public/java/src/or...
> mojo/public/java/src/org/chromium/mojo/system/Core.java:44: public WaitFlags
> readable(boolean readable) {
> On 2014/04/17 13:50:24, qsr wrote:
> > On 2014/04/17 13:15:42, bulach wrote:
> > > nit: should this be a setReadable / setWritable below?
> > 
> >  Done. (I have answered on this on your previous comments, but you didn't
> > respond, so I guessed your were fine for flags. My argument was that this is
> > more a builder than an POJO, and I founded doing:
> > 
> > Flags.none().readable(true).foo(true).bar(true) was nicer than:
> > Flags.none().setReadable(true).setFoo(true).setBar(true)
> 
> sorry, I thought on our meeting I said to keep similar to other "data holders"
> like protobuf, which I think have setters... anyways, thanks for doing this!

 I thought we were speaking about naked field. I didn't get that you were
speaking about this too. Anyway, doesn't matter enough to spend more time on
this :)

> 
>
https://codereview.chromium.org/228723002/diff/210001/mojo/system/android/src...
> File mojo/system/android/src/org/chromium/mojo/system/CoreImpl.java (right):
> 
>
https://codereview.chromium.org/228723002/diff/210001/mojo/system/android/src...
> mojo/system/android/src/org/chromium/mojo/system/CoreImpl.java:23: public
class
> CoreImpl implements Core {
> On 2014/04/17 13:50:24, qsr wrote:
> > On 2014/04/17 13:15:42, bulach wrote:
> > > nit: can these impl classes be package-private?
> > 
> >  Most of those can, this one can't. We need to get the singleton. And
probably
> > from other place than here.
> 
> looks like the getInstance() is only called on tests for now, and hopefully
> won't be used outside this package in the future, right?
> probably best to keep it package-private for now, and make it public later on
if
> needed, and even then, it'd probably be nicer to expose a separate class
> returning the getInstance() as a Core rather than a CoreImpl...

 Hum. GetInstance does return a Core, and not a CoreImpl. There is not way to
get a CoreImpl with any public interface. Now, would you prefer that this
factory be out of Core, with something like CoreSingleton::GetInstance? If yes,
I can do it on this CL, because we will need a way to get a Core from outside of
this package.

[viettrungluu, 2014-04-17 14:50:56]

https://codereview.chromium.org/228723002/diff/210001/mojo/public/java/src/or...
File mojo/public/java/src/org/chromium/mojo/system/Core.java (right):

https://codereview.chromium.org/228723002/diff/210001/mojo/public/java/src/or...
mojo/public/java/src/org/chromium/mojo/system/Core.java:33: private static final
int FLAG_NONE = 0;
On 2014/04/17 14:04:50, bulach wrote:
> On 2014/04/17 13:50:24, qsr wrote:
> > On 2014/04/17 13:15:42, bulach wrote:
> > > nit: it'd be nice to share these flags with the native side using the
> template
> > > mechanisms, similar to:
> > >
> >
>
https://code.google.com/p/chromium/codesearch#chromium/src/net/base/net_error...
> > 
> >  @viettrungluu what do you think? Do we want to do something like this?
> > 
> >  @bulach -> Are we agreeing that this can be submitted, and then evolve if
we
> > add this kind of mechanism?
> 
> I don't care much about the order of patches, but would strongly suggest that
> the end goal should reuse / share the values across java and c++: we're using
> the template mechanism mentioned above in various other places and it the long
> run it makes life much easier...
> 
> if you want to do as a follow up, or if you prefer to extract from the current
> mojo system before this patch, I'll leave it to you.. :)
> 
> and to be clear: I would not suggest to do it as part of this patch..

I don't think we want to do anything like this in general:
- these values/APIs shouldn't be updated very often anyway (and in any case,
only added to)
- such techniques (like net_error_list.h) are only viable for some small-ish set
of languages, and may also lead to unidiomatic naming of flags, etc.
- ... unless we just generate such lists using some tool, which seems like
overkill

[bulach, 2014-04-17 14:56:32]

On 2014/04/17 14:26:45, qsr wrote:
> On 2014/04/17 14:04:50, bulach wrote:
> > thanks ben! some clarifications inline:
> > 
> >
>
https://codereview.chromium.org/228723002/diff/210001/mojo/public/java/src/or...
> > File mojo/public/java/src/org/chromium/mojo/system/Core.java (right):
> > 
> >
>
https://codereview.chromium.org/228723002/diff/210001/mojo/public/java/src/or...
> > mojo/public/java/src/org/chromium/mojo/system/Core.java:33: private static
> final
> > int FLAG_NONE = 0;
> > On 2014/04/17 13:50:24, qsr wrote:
> > > On 2014/04/17 13:15:42, bulach wrote:
> > > > nit: it'd be nice to share these flags with the native side using the
> > template
> > > > mechanisms, similar to:
> > > >
> > >
> >
>
https://code.google.com/p/chromium/codesearch#chromium/src/net/base/net_error...
> > > 
> > >  @viettrungluu what do you think? Do we want to do something like this?
> > > 
> > >  @bulach -> Are we agreeing that this can be submitted, and then evolve if
> we
> > > add this kind of mechanism?
> > 
> > I don't care much about the order of patches, but would strongly suggest
that
> > the end goal should reuse / share the values across java and c++: we're
using
> > the template mechanism mentioned above in various other places and it the
long
> > run it makes life much easier...
> > 
> > if you want to do as a follow up, or if you prefer to extract from the
current
> > mojo system before this patch, I'll leave it to you.. :)
> > 
> > and to be clear: I would not suggest to do it as part of this patch..
> > 
> >
>
https://codereview.chromium.org/228723002/diff/210001/mojo/public/java/src/or...
> > mojo/public/java/src/org/chromium/mojo/system/Core.java:44: public WaitFlags
> > readable(boolean readable) {
> > On 2014/04/17 13:50:24, qsr wrote:
> > > On 2014/04/17 13:15:42, bulach wrote:
> > > > nit: should this be a setReadable / setWritable below?
> > > 
> > >  Done. (I have answered on this on your previous comments, but you didn't
> > > respond, so I guessed your were fine for flags. My argument was that this
is
> > > more a builder than an POJO, and I founded doing:
> > > 
> > > Flags.none().readable(true).foo(true).bar(true) was nicer than:
> > > Flags.none().setReadable(true).setFoo(true).setBar(true)
> > 
> > sorry, I thought on our meeting I said to keep similar to other "data
holders"
> > like protobuf, which I think have setters... anyways, thanks for doing this!
> 
>  I thought we were speaking about naked field. I didn't get that you were
> speaking about this too. Anyway, doesn't matter enough to spend more time on
> this :)

sorry about the confusion! all sorted anyways... :)

> 
> > 
> >
>
https://codereview.chromium.org/228723002/diff/210001/mojo/system/android/src...
> > File mojo/system/android/src/org/chromium/mojo/system/CoreImpl.java (right):
> > 
> >
>
https://codereview.chromium.org/228723002/diff/210001/mojo/system/android/src...
> > mojo/system/android/src/org/chromium/mojo/system/CoreImpl.java:23: public
> class
> > CoreImpl implements Core {
> > On 2014/04/17 13:50:24, qsr wrote:
> > > On 2014/04/17 13:15:42, bulach wrote:
> > > > nit: can these impl classes be package-private?
> > > 
> > >  Most of those can, this one can't. We need to get the singleton. And
> probably
> > > from other place than here.
> > 
> > looks like the getInstance() is only called on tests for now, and hopefully
> > won't be used outside this package in the future, right?
> > probably best to keep it package-private for now, and make it public later
on
> if
> > needed, and even then, it'd probably be nicer to expose a separate class
> > returning the getInstance() as a Core rather than a CoreImpl...
> 
>  Hum. GetInstance does return a Core, and not a CoreImpl. There is not way to
> get a CoreImpl with any public interface. Now, would you prefer that this
> factory be out of Core, with something like CoreSingleton::GetInstance? If
yes,
> I can do it on this CL, because we will need a way to get a Core from outside
of
> this package.

ahn, I see... let's keep it you have it, the extra indirection wouldn't add much
at this stage..

[bulach, 2014-04-17 15:05:38]

On 2014/04/17 14:50:56, viettrungluu wrote:
>
https://codereview.chromium.org/228723002/diff/210001/mojo/public/java/src/or...
> File mojo/public/java/src/org/chromium/mojo/system/Core.java (right):
> 
>
https://codereview.chromium.org/228723002/diff/210001/mojo/public/java/src/or...
> mojo/public/java/src/org/chromium/mojo/system/Core.java:33: private static
final
> int FLAG_NONE = 0;
> On 2014/04/17 14:04:50, bulach wrote:
> > On 2014/04/17 13:50:24, qsr wrote:
> > > On 2014/04/17 13:15:42, bulach wrote:
> > > > nit: it'd be nice to share these flags with the native side using the
> > template
> > > > mechanisms, similar to:
> > > >
> > >
> >
>
https://code.google.com/p/chromium/codesearch#chromium/src/net/base/net_error...
> > > 
> > >  @viettrungluu what do you think? Do we want to do something like this?
> > > 
> > >  @bulach -> Are we agreeing that this can be submitted, and then evolve if
> we
> > > add this kind of mechanism?
> > 
> > I don't care much about the order of patches, but would strongly suggest
that
> > the end goal should reuse / share the values across java and c++: we're
using
> > the template mechanism mentioned above in various other places and it the
long
> > run it makes life much easier...
> > 
> > if you want to do as a follow up, or if you prefer to extract from the
current
> > mojo system before this patch, I'll leave it to you.. :)
> > 
> > and to be clear: I would not suggest to do it as part of this patch..
> 
> I don't think we want to do anything like this in general:
> - these values/APIs shouldn't be updated very often anyway (and in any case,
> only added to)
> - such techniques (like net_error_list.h) are only viable for some small-ish
set
> of languages, and may also lead to unidiomatic naming of flags, etc.
> - ... unless we just generate such lists using some tool, which seems like
> overkill

sorry, I wasn't suggesting to use that mechanism for every constant in every
language combination :)

however, for java/C++ sharing, it has proved fairly useful in reducing
duplication and the inconsistencies the inevitably arise.
more usage here:
https://code.google.com/p/chromium/codesearch#search/&q=java_cpp_template.gypi

you certainly know more about these constants than I do, so if you think they'll
be static overtime, let's keep as is.
(other constants have been more, erm, "fluid" overtime...).

[qsr, 2014-04-18 09:01:41]

@viettrungluu ping for placement, +ownership.

[bulach, 2014-04-22 08:45:22]

lgtm for the java part (but as mentioned in #14, I'm not an owner around here..)

[viettrungluu, 2014-04-22 16:06:26]

LGTM with the files moved as you suggested. (I don't see any gles2 files right
now, so I don't know what would go in android/gles2.)

[qsr, 2014-04-23 08:15:52]

On 2014/04/22 16:06:26, viettrungluu wrote:
> LGTM with the files moved as you suggested. (I don't see any gles2 files right
> now, so I don't know what would go in android/gles2.)

 Hum, my bad there, didn't look into it, and misunderstood your #6 comment.
Nothing in gles2 yet.

[qsr, 2014-04-23 08:16:01]

The CQ bit was checked by [email protected]

[commit-bot: I haz the power, 2014-04-23 08:16:22]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/[email protected]/228723002/250001

[commit-bot: I haz the power, 2014-04-23 08:29:57]

The CQ bit was unchecked by [email protected]

[commit-bot: I haz the power, 2014-04-23 08:29:57]

Retried try job too often on android_clang_dbg for step(s) slave_steps
http://build.chromium.org/p/tryserver.chromium/buildstatus?builder=android_cl...

[qsr, 2014-04-23 08:50:34]

The CQ bit was checked by [email protected]

[commit-bot: I haz the power, 2014-04-23 08:50:55]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/[email protected]/228723002/250001

[commit-bot: I haz the power, 2014-04-23 09:32:55]

The CQ bit was unchecked by [email protected]

[commit-bot: I haz the power, 2014-04-23 09:32:56]

Retried try job too often on android_dbg for step(s) slave_steps
http://build.chromium.org/p/tryserver.chromium/buildstatus?builder=android_db...

[qsr, 2014-04-23 10:47:51]

The CQ bit was checked by [email protected]

[commit-bot: I haz the power, 2014-04-23 10:54:28]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/[email protected]/228723002/250001

[commit-bot: I haz the power, 2014-04-23 12:20:12]

The CQ bit was unchecked by [email protected]

[commit-bot: I haz the power, 2014-04-23 12:20:12]

Retried try job too often on android_dbg for step(s) slave_steps
http://build.chromium.org/p/tryserver.chromium/buildstatus?builder=android_db...

[qsr, 2014-04-23 12:47:10]

The CQ bit was checked by [email protected]

[commit-bot: I haz the power, 2014-04-23 12:47:23]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/[email protected]/228723002/270001

[commit-bot: I haz the power, 2014-04-23 13:33:02]

The CQ bit was unchecked by [email protected]

[commit-bot: I haz the power, 2014-04-23 13:33:03]

Try jobs failed on following builders:
  tryserver.chromium on chromium_presubmit

[qsr, 2014-04-23 14:26:36]

The CQ bit was checked by [email protected]

[commit-bot: I haz the power, 2014-04-23 14:26:49]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/[email protected]/228723002/270001

[commit-bot: I haz the power, 2014-04-23 16:02:36]

Change committed as 265658