First of all, a bit of context: WebSMS work began before Fennec Native UI was in the tree and at that time, AFAIK, there was only one way to do C++ <-> Java communications: using JNI (AndroidBridge and AndroidJNI). It seems that there are now new ways to do that and we have been asked to use those to unblock WebSMS Android implementation from landing in m-c. I had the chance to look at this API when implementing Network API and here is what I understood: * Sending messages from Java to C++: You have to create a GeckoEvent in the Java code, pass some parameters and call GeckoAppShell.sendEventToGecko(). You don't have to care about the JNI boilerplate anymore but there is a lot of boilerplate you have to do: - specify the event id, the member variables and a new ctor in GeckoEvent.java - mirror those changes with the other GeckoEvent.java file - set the same event id, the same members, getters for those members, and jFieldID for them too in AndroidJavaWrappers.h - initialize jFieldID's values with 0, re-initialize them with the correct field they have to be associated with and implement the parsing/getting in AndroidJavaWrappers.cpp - put the real implementation in a big switch block in nsAppShell.cpp The old way is the following: - declare a method as native in GeckoAppShell.java - mirror it in the other GeckoAppShell.java - put two lines of boilerplate in APKOpen.cpp - do the implementation in AndroidJNI.cpp So with the message passing API it seems that we have to write more boilerplate and in more files. It doesn't seem better regarding performance (this GeckoEvent object is going to be really big soon) and it is going to be harder to maintain (GeckoEvent has one ctor signature for each kind of event and signatures are like (int,int,int), this is going to fail). Also, considering how long I took to find where to put the implementation of NETWORK_CHANGED event in nsAppShell.cpp, it is unlikely simpler. Finally, even if it's quite uncommon, we can't return values with that API but JNI allows us to do so. * Sending messages from C++ to Java: AFAIUI, the new way is to call AndroidBridge::HandleGeckoMessage which takes a JSON formatted string and return a JSON formatted string as a result. IMO, doing this from C++ is insane. To conclude, my impression is that we are asking to use an API that appeared *during* the WebSMS work and that doesn't seem to provide any clear benefit compared to the old way. And to be clear, I know that changing to that new API wouldn't take an horrible amount of work (though, I've no idea for the JSON part) but for the reason given above, I do not think we should do that at all, it is not about how long it would take.

The question here is over the java/c++ ffi. To be clear, no one is discussing the java/javascript ffi. We currently use JNI for our java/c++ ffi. It sucks because - requires some gross boilerplate It doesn't suck because - statically typed - JNI is the C++/java FFI, and it's well optimized - doesn't create java garbage unless necessary We can autogenerate the JNI boilerplate. That's bug 689493. The proposal is to switch our java/c++ ffi to json+geckoevent. To be clear, no one is discussing the java/javascript ffi. A C++->Java ffi built on JSON sucks because - requires some gross boilterplate in C++ and java - dynamically typed - omgslow - always creates java garbage It doesn't suck because - ??? I'm told there's currently no C++ code in the tree using the json ffi. We could autogenerate the C++ side of the JSON boilerplate. Maybe the java side, but that'd be harder. A java->C++ ffi built on a single java class that carries the union (not union in the C sense, but in the set theoretical sense; it's >=132 bytes and growing, modulo alignment) of all possible data sent java->c++ and dynamically dispatched upon sucks because - it's a separate ffi to maintain - requires some gross boilerplate - dynamically typed - slow compared to JNI - always creates java garbage It doesn't suck because - ??? We need very very clear and careful arguments for the json/geckoevent ffi. Again, no one is discussing the java/javascript ffi.

Let's continue to make gecko/C++ easier to hack on, not harder.