Does Mojo have a stable Java interface?

[Adam Barth]

Hi mojo-dev,

Over in Flutter-land, we're looking at letting third-party developers create modules that contain Mojo services.  The idea is that these modules will be combined together on the end-developer's machine as part of the process that builds the production APK or IPA for their Flutter app.

For iOS, the approach seems straightforward.  We'll ask third-party developers to create iOS frameworks that contain a dynamic library.  We'll then load the dylib and inject the Mojo system thunk table in the same way that mojo_shell does today.  To discover the service implementations, we'll probably define an Objective-C protocol that the dylib implements.

For Android, we'll want something similar for Java.  Does Mojo have a stable Java interface?  Specifically, is https://github.com/domokit/mojo/tree/master/mojo/public/java intended to be binary stable?  More operationally, if we tell developers to build jars against those definitions, will we be able to continue loading those jars as the system evolves?

Obviously we know that Mojo isn't done and that there are likely to be breaking changes to even the Mojo C ABI as the system evolves.  However, I'd like to make sure we're building out the service ecosystem for Flutter in a way that harmonizes with the larger Mojo ecosystem.  Any advice on this topic would be appreciated.

Thanks!

Adam

[Benjamin Lerman]

For Android, we'll want something similar for Java.  Does Mojo have a stable Java interface?  Specifically, is https://github.com/domokit/mojo/tree/master/mojo/public/java intended to be binary stable?  More operationally, if we tell developers to build jars against those definitions, will we be able to continue loading those jars as the system evolves?

So, non-withstanding that nothing is stable yet, the idea is that mojo/public/java/system is a stable API, but mojo/public/java/bindings and mojo/public/java/application are not. When you write a mojo application, you bring with you (put in your jar) bindings and application so that they match the version of the code generator you use. system on the other hand is provided by the content handler and allows you to access the mojo apis.

[Adam Barth]

On Wed, Feb 3, 2016 at 1:11 AM Benjamin Lerman <q...@chromium.org> wrote:

For Android, we'll want something similar for Java.  Does Mojo have a stable Java interface?  Specifically, is https://github.com/domokit/mojo/tree/master/mojo/public/java intended to be binary stable?  More operationally, if we tell developers to build jars against those definitions, will we be able to continue loading those jars as the system evolves?

So, non-withstanding that nothing is stable yet, the idea is that mojo/public/java/system is a stable API, but mojo/public/java/bindings and mojo/public/java/application are not. When you write a mojo application, you bring with you (put in your jar) bindings and application so that they match the version of the code generator you use. system on the other hand is provided by the content handler and allows you to access the mojo apis.

That makes good sense, thanks.  If I have multiple jars produced by different developers in the same JVM, so I need to do anything special to make sure mojo/public/java/bindings and mojo/public/java/application don't collide while being able to share mojo/public/java/system?  For example, do I need to pull any tricks with the class loader or anything?

Thanks!

Adam

[Benjamin Lerman]

That makes good sense, thanks.  If I have multiple jars produced by different developers in the same JVM, so I need to do anything special to make sure mojo/public/java/bindings and mojo/public/java/application don't collide while being able to share mojo/public/java/system?  For example, do I need to pull any tricks with the class loader or anything?

 Yes, you will have to play with the class loader and mostly use a different class loader for each of them so that they do not step on one another. The java content handler is doing this in mojo (it is probably more complicated that your use case, because it also needs to handle native code). 

[Jeff Brown]

I wouldn't count on having to perform fancy class loader tricks on Android.  Apps in general cannot control their initial class loader so any classes the Android Framework instantiates directly (Activities, Services, etc.) need to be loadable along with their dependencies.  (It's possible to work around this but painful and intrusive.)

Anyhow, I don't think this is a ship stopper.  We'll just need to develop appropriate tooling or conventions if folks are including multiple libraries with Mojo dependencies into their projects.  This could involve some combination of factoring out common code, requiring use of the same versions of common code, static linkage, jarjar-based package renaming, or obfuscation.  Can be dealt with later.

Jeff.

On Wed, Feb 3, 2016 at 8:51 AM Benjamin Lerman <q...@chromium.org> wrote:

That makes good sense, thanks.  If I have multiple jars produced by different developers in the same JVM, so I need to do anything special to make sure mojo/public/java/bindings and mojo/public/java/application don't collide while being able to share mojo/public/java/system?  For example, do I need to pull any tricks with the class loader or anything?

 Yes, you will have to play with the class loader and mostly use a different class loader for each of them so that they do not step on one another. The java content handler is doing this in mojo (it is probably more complicated that your use case, because it also needs to handle native code). 

--
You received this message because you are subscribed to the Google Groups "mojo-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mojo-dev+u...@chromium.org.

[Adam Barth]

It seems like we'll run into this problem as soon as we have third-party Java services.  For example, suppose an end-developer wants to use two third-party Java services that were built against different versions of the Mojo Java bindings.  Unless we do something to address this problem, won't the end-developer be stuck?

Adam

[Jeff Brown]

Yes.  But developers already encounter this problem when linking other libraries like the android support library or the GMS Core client library which is not guaranteed to be binary compatible.  In general, the Android library story has many such issues.

The problem definitely exists but we might be able to get away with fairly simplistic linkage conventions in the short term, such as requiring that everyone at least agree on the using the same version of the Mojo bindings library.  Not ideal of course but it's a start.

Jeff.

[James Robinson]

Aside from the stability and linkage issues, the current Java bindings layer is not ideal for Flutter developers.  The biggest issue is that it is a Java bindings layer and not Android so that it can (in theory, at least) run on non-Android Java platforms like servers.  This means that the bindings layer does not use any of the Android standard libraries containers or utilities and that it's generally more allocation-heavy than you would really want for running inside an Android runtime.  It will also likely feel foreign to developers accustomed to Android.  Developers writing Android Java would be happier and have a more efficient program if they were to use bindings that were built specifically for the Android flavor of Java.

- James

You received this message because you are subscribed to the Google Groups "Flutter Dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to flutter-dev...@googlegroups.com.
To post to this group, send email to flutt...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/flutter-dev/CAOW3Ud0znEiUs-A%3D7F64Juhq3v%3D2stf8ZuP_M663cuLho171VA%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.

[Jeff Brown]

+100!  Yes this exactly.

We should write an Android-specific bindings layer.

Jeff.