Adding a router class to handle messages that expect responses.

mojo/bindings/java/src/org/chromium/mojo/bindings/MessageReceiverWithResponder.java

Index: mojo/bindings/java/src/org/chromium/mojo/bindings/MessageReceiverWithResponder.java
diff --git a/mojo/bindings/java/src/org/chromium/mojo/bindings/MessageReceiverWithResponder.java b/mojo/bindings/java/src/org/chromium/mojo/bindings/MessageReceiverWithResponder.java
new file mode 100644
index 0000000000000000000000000000000000000000..7e80cb1fa09a70e895bbea076a677d7273fc5f1e
--- /dev/null
+++ b/mojo/bindings/java/src/org/chromium/mojo/bindings/MessageReceiverWithResponder.java
@@ -0,0 +1,19 @@
+// Copyright 2014 The Chromium Authors. All rights reserved.
+// Use of this source code is governed by a BSD-style license that can be
+// found in the LICENSE file.
+
+package org.chromium.mojo.bindings;
+
+/**
+ * A {@link MessageReceiver} that can also handle the handle the response message generated from the
+ * given message.
+ */
+public interface MessageReceiverWithResponder extends MessageReceiver {
+
+    /**
+     * A variant on Accept that registers a MessageReceiver (known as the responder) to handle the

[rmcilroy, 2014/07/10 19:03:58]

A variant on {@link MessageReceiver#accept()} that registers a {@link
MessageReceiver} (known as the responder) to handle the response message
generated from the given message.  The responder's {@link
MessageReceiver#accept()} method will only be called after the response message
has been received, which will always be after this method returns.

(looking at RouterImpl, it looks like the accept message never gets called from
within acceptWithResponder as far as I can tell, and this is a good thing - from
experience, not knowing whether a callback will be called synchronously from
within a method or posted to be called asynchronously later is a really bad idea
and causes tricky bugs - I think you should just specify that the responder's
accept method will always be called after this method returns.

[qsr, 2014/07/11 11:42:08]

 The issue with this is that it will force implementation of every service to
have this constraint on their callbacks, as in the very rare case where the
proxy is directly connected to the stub, this is what will happen -> the router
will not call the accept method in this method, and but it will call the accept
method of the stub, that will call the implementation, that will call the
callback, that will call the router that will call the accept.

 The C++ implementation allows this to happen.

[rmcilroy, 2014/07/14 14:44:56]

Hmm, I really think this is generally a bad idea, but if the other mojo bindings
allow this I guess there isn't anything we can do to avoid it.  Thanks for
updating the rest of the JavaDoc

+     * response message generated from the given message. The responder's Accept method may be
+     * called during AcceptWithResponder or some time after its return.
+     */
+    boolean acceptWithResponder(Message message, MessageReceiver receiver);

[rmcilroy, 2014/07/10 19:03:58]

/s/receiver/responder

[qsr, 2014/07/11 11:42:08]

Done.

+}