Though it's not without compromises — because of Google's stupid policy that "nothing goes into the system unless it needs direct access to privileged or private system components", RecyclerView, ViewPager, and some other basic UI components are still AndroidX libraries that depend on AppCompat for no good reason. I had to fork them to rid them of that dependency: https://github.com/grishka/LiteX
Is this a supported thing to do? No. Do I care about it being unsupported? Also no.
IME biggest dependencies are not compat libraries or _typical_ dependencies that Android apps need (like image loaders), but anything that involves native code. Media capabilities is one thing, but also solutions for analytics/user monitoring/SDKs for integration with Important Companies are more often than not _massive_, and companies like to track the user from many angles ¯\_(ツ)_/¯
If your app wants to use features which behave differently depending on the OS version, you have to if/else over the OS version. Also, note that the platform's Fragment implementation is deprecated and you might miss ViewModel.
I never ever saw anyone doing it for desktop or server applications.
You can manually remove dependencies or.. I think in the Android world you specify what classes can be reflected on and then strip unused code with Proguard (though I could never get it working with Clojure)
Would love to be corrected if I got any of it wrong
On Java's case, all AOT toolchains and embedded deployment workflows have supported similar capabilities.
I’m pretty sure that’s exactly what the Google Closure Compiler does: https://developers.google.com/closure/compiler/docs/limitati...
Though it has a ton of restrictions on how you write code and how you can use reflection.
Like JavaScript?
If you are limiting tooling to subsets, you can also compile subsets of Python or Javascript to machine code.
Even C++ you mention does that - you have explicit __attribute__ calls to avoid linker from dropping code you want to keep for reflection purposes.