toward using C++/WinRT to develop Android apps as part of “DLL all the things”

[optikos]

analogous to the corresponding iOS-related issue #330, but now focus on analyzing what it would take for C++/WinRT to target Android instead

Unlike objc2winmd within Project Islandwood's WinObjC's excellent body of work, there is no jvm2winmd projector of JVM-based modules that would permit (forcibly) invoking Java APIs via JNI analogous to the way that Xamamin.Android does for Mono-based C# and F# development of Android apps. Project Astoria is cancelled, which was the most likely place from which such a projector would have originated.

As apparently effectively indicated by Miguel de Icaza himself on 23 January 2018, Mono lacks the ability to participate in the .winMD world for the foreseeable future, so there is little hope there of utilizing unmodified Mono-based Xamarin.Android to generate .winMD files for JVM-based modules, even though Xamarin.Android generates analogous language projections to C# and to F# via Mono techniques, not via .winMD-based techniques.

Does any .winMD projection of JVM-based modules' APIs exist (even internal within Microsoft)? Does there exist any (even contorted?) way of generating .winMD & .DLL files of WinRT components from Xamarin.Android's C# and F# language projection?

To the latter question, if Android.Xamarin had preXamarin-Microsoft's .NET proper instead of Mono, then 1) MSbuild could conceivably generate WinRT components for each JVM-based module (perhaps with a tiny amount of Xamarin.Android C# wrapper code around each JVM-based module, where that wrapper could be code-generated trivially); or 2) a freshly-written tool could be authored to invoke .NET APIs to generate .winMD files for each JVM-based module, with the corresponding .DLL built from C# or C++/CX or C++/WinRT or F# or VisualBasic source code that (forcibly) invokes each Java method via the JNI, much as Xamarin.Android works. That source code for the .DLL could be code-generated nontrivially by an AST-based Roslyn-based tool, since C#'s Roslyn is the most open-sourced of all of aforementioned {C#, C++/CX, C++/WinRT with cppwinrt.exe, F#} nonXamarin/nonMono compilers/languages.

Does there exist a way to coerce Xamarin.Android's C# language projection to play nicely with nonMono (preXamarin-Microsoft-true-).NET's №1 or №2 above, such as adding /target:winmdobj to nonMono (preXamarin-Microsoft-true-).NET C# build of the Xamarin.Android projection of the JVM-based module's API? Is there any way to pull or push Xamarin.Android's C# projection of the JVM-based module's API over to nonMono (preXamarin-Microsoft-true-).NET C# (or to C++/CX or VisualBasic or F#, for that matter)?

Or equivalently, is there a way for Microsoft to open source the (suspected) jvm2winmd portion of Project Astoria to GitHub analogous to objc2winmd despite Project Astoria being cancelled?

[devhawk]

Questions about interop between JVM and C# seem out of scope for this project

[optikos]

@devhawk, well then ignore those sentences about JVM and C#, as they were merely food for thought. Instead focus entirely on some other mechanism of somehow obtaining a C++ presentation of Java API to feed into a C++/AndroidRT that looks like C++/WinRT to the app's source code, but (forcibly) invokes Android SDK's Java APIs via the JNI.

[optikos]

For example, Mono's Embedinnator-4000 shows some hope of harvesting all the Java APIs from Xamarin.Android's .NET assemblies to generate some sort of C++ projection via its --gen=C++ and --target=Android command-line arguments. It seems that Embedinnator-4000 could be evolved to be C++/AndroidRT's analogue of cppwinrt.exe by evolving Embedinnator-4000's current C++ projection to optionally instead surface the personality that C++/WinRT presents to app-domain source code. The deeper the surfacing of a much more internal C++/WinRT personality, the better, so that C++/WinRT (and C++/ObjCRT) and C++/AndroidRT diverge only in their guts with vast sameness in their meta-model‡ from some layer on upwards to craft a single C++/RT app-development personality (borrowed wholesale without modification from C++/WinRT's app-facing personality).

‡ ignoring the UWP versus Android (versus iOS versus MacOS versus Tizen versus Google FusciaOS) classes & APIs that are concretely presented by the meta-model

In this vision of the future, C++/AndroidRT wouldn't merely •mimic• Xamarin.Android's (forcible) invocation of Java APIs via the JNI; C++/AndroidRT would actually invoke Xamarin.Android's .NET assemblies (analogous to C++/WinRT invoking UWP's WinRT components). Then Xamarin.Android itself would then in turn do the (forcible) invocation of Java APIs via the JNI as we are all accustomed to with Xamarin.Android. All the while, C++/AndroidRT would be presenting the exact same meta-model personality of C++/WinRT to the app-domain source code, merely presenting Android's classes & APIs instead of UWP's classes & APIs.

[optikos]

regarding the Android analogue of the sibling iOS issue's comment

Conversely, the reasons for C++/AndroidRT(2.0-bypassing-Xamarin.Android) to exist seems to hang its hat on only a single nail: reducing the so-called impedance mismatch of an app's UI code and an app's backend-processing libraries (by moving the unfortunately-required JVM-based impedance mismatch out of app-domain source code into a library/framework/infrastructural guts hidden from the app-domain source code).

The scenarios where a C++/AndroidRT application would significantly outperform today's Java-in-JVM-JNIing-with-C++-backend-processing is where the Java source code is doing non-UI processor-cycle-intensive processing. If Java is doing so much processing in JVMland, then why wasn't it migrated to a C++ backend-processing library? So the speed-improvement reason for C++/AndroidRT to exist would be non-UI processing performed gratuitously by Java that for some reason people are loathe to migrate today to backend-processing libraries in C++ (but that C++/AndroidRT could do the heavy lifting of porting once for everyone). Finding such Java-today-but-C++AndroidRT-tomorrow non-UI operations is for further study.

[optikos]

Over on the corresponding issue #330 for a C++/ObjCRT, I think that we have explored vicariously/surrogately quite a few avenues of this potential future for an extrapolation of C++/WinRT to a C++/AndroidRT as part of a C++/RT family of C++/WinRT-esque C++ language projections for other OSes' SDKs in other OSes' runtimes, and perhaps eventually a C++/uberRT to permit writing portable app-domain source code for those UI constructs that all other OSes' UI/UX has in common (vaguely analogous to Xamarin.Forms, but perhaps with a drastically different software architecture). Along some of these avenues, it seems Mono's Embeddinator-4000 might be the furthest along to serve a cppwinrt.exe-like functionality for a C++/AndroidRT. Extending Embeddinator-4000 might be the path of least resistance for anyone seeking a C++/AndroidRT. It will be interesting to see what Mono eventually generates as its language projection for C++ for JVM-based runtimes in Embeddinator-4000; work had been progressing there somewhat during 2017. In one potential future, perhaps that Mono work (also Microsoft-based) will borrow heavily from C++/WinRT. Or in another potential future, perhaps Mono will devise a drastically different family of C++ language projections, one of which might be to Windows 10 editions, hence forming a(n unfortunate) competitor of sorts to C++/WinRT.

Thank you everyone (especially Kenny Kerr) for patiently allowing an at-time free-wheeling discussion of a potential future without closing this issue prematurely. For now, I am going to close this issue, so that if any aspect of this broad topic arises again by anybody, new issue(s) can be opened on finer granularities of C++/WinRT-extrapolated-to-other-OSes topics.