{"action":"created","issue":{"url":"https://api.github.com/repos/Microsoft/cppwinrt/issues/331","repository_url":"https://api.github.com/repos/Microsoft/cppwinrt","labels_url":"https://api.github.com/repos/Microsoft/cppwinrt/issues/331/labels{/name}","comments_url":"https://api.github.com/repos/Microsoft/cppwinrt/issues/331/comments","events_url":"https://api.github.com/repos/Microsoft/cppwinrt/issues/331/events","html_url":"https://github.com/Microsoft/cppwinrt/issues/331","id":297612285,"number":331,"title":"toward using C++/WinRT to develop Android apps as part of “DLL all the things”","user":{"login":"optikos","id":8305887,"avatar_url":"https://avatars3.githubusercontent.com/u/8305887?v=4","gravatar_id":"","url":"https://api.github.com/users/optikos","html_url":"https://github.com/optikos","followers_url":"https://api.github.com/users/optikos/followers","following_url":"https://api.github.com/users/optikos/following{/other_user}","gists_url":"https://api.github.com/users/optikos/gists{/gist_id}","starred_url":"https://api.github.com/users/optikos/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/optikos/subscriptions","organizations_url":"https://api.github.com/users/optikos/orgs","repos_url":"https://api.github.com/users/optikos/repos","events_url":"https://api.github.com/users/optikos/events{/privacy}","received_events_url":"https://api.github.com/users/optikos/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":3,"created_at":"2018-02-15T22:02:12Z","updated_at":"2018-02-22T18:35:50Z","closed_at":null,"author_association":"NONE","body":"analogous to the corresponding [iOS-related issue #330](https://github.com/Microsoft/cppwinrt/issues/330), but now focus on analyzing what it would take for C++/WinRT to target Android instead\r\n\r\nUnlike 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.\r\n\r\nAs 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](https://trello.com/c/fJydsseM/43-add-winmd-support-to-mono), 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.\r\n\r\nDoes 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?\r\n\r\nTo  the latter question, if Android.Xamarin had preXamarin-Microsoft's .NET proper instead of Mono, then\r\n1) [MSbuild could conceivably generate WinRT components](https://docs.microsoft.com/en-us/previous-versions/windows/apps/br230301%28v%3dvs.140%29) 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\r\n2) a freshly-written tool could be authored to invoke [.NET APIs to generate .winMD files](https://docs.microsoft.com/en-us/dotnet/api/microsoft.build.tasks.winmdexp?view=netframework-4.7.1) 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.\r\n\r\nDoes 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](https://docs.microsoft.com/en-us/dotnet/csharp/language-reference/compiler-options/target-winmdobj-compiler-option) 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)?\r\n\r\nOr equivalently, is there a way for Microsoft to open source the (suspected) jvm2winmd portion of Project Astoria to GitHub analogous to [objc2winmd](https://github.com/Microsoft/WinObjC/tree/develop/tools/objc2winmd) despite Project Astoria being cancelled?"},"comment":{"url":"https://api.github.com/repos/Microsoft/cppwinrt/issues/comments/367777393","html_url":"https://github.com/Microsoft/cppwinrt/issues/331#issuecomment-367777393","issue_url":"https://api.github.com/repos/Microsoft/cppwinrt/issues/331","id":367777393,"user":{"login":"optikos","id":8305887,"avatar_url":"https://avatars3.githubusercontent.com/u/8305887?v=4","gravatar_id":"","url":"https://api.github.com/users/optikos","html_url":"https://github.com/optikos","followers_url":"https://api.github.com/users/optikos/followers","following_url":"https://api.github.com/users/optikos/following{/other_user}","gists_url":"https://api.github.com/users/optikos/gists{/gist_id}","starred_url":"https://api.github.com/users/optikos/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/optikos/subscriptions","organizations_url":"https://api.github.com/users/optikos/orgs","repos_url":"https://api.github.com/users/optikos/repos","events_url":"https://api.github.com/users/optikos/events{/privacy}","received_events_url":"https://api.github.com/users/optikos/received_events","type":"User","site_admin":false},"created_at":"2018-02-22T18:35:50Z","updated_at":"2018-02-22T18:35:50Z","author_association":"NONE","body":"regarding the Android analogue of the [sibling iOS issue's comment](https://github.com/Microsoft/cppwinrt/issues/330#issuecomment-367770941)\r\n\r\nConversely, 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).\r\n\r\nThe 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."}}
{"actor":{"display_login":"optikos"}}