104
Why does Android bother with Java?
(lemmy.world)
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
this post was submitted on 02 Jul 2023
104 points (95.6% liked)
Android
27830 readers
117 users here now
DROID DOES
Welcome to the droidymcdroidface-iest, Lemmyest (Lemmiest), test, bestest, phoniest, pluckiest, snarkiest, and spiciest Android community on Lemmy (Do not respond)! Here you can participate in amazing discussions and events relating to all things Android.
The rules for posting and commenting, besides the rules defined here for lemmy.world, are as follows:
Rules
1. All posts must be relevant to Android devices/operating system.
2. Posts cannot be illegal or NSFW material.
3. No spam, self promotion, or upvote farming. Sources engaging in these behavior will be added to the Blacklist.
4. Non-whitelisted bots will be banned.
5. Engage respectfully: Harassment, flamebaiting, bad faith engagement, or agenda posting will result in your posts being removed. Excessive violations will result in temporary or permanent ban, depending on severity.
6. Memes are not allowed to be posts, but are allowed in the comments.
7. Posts from clickbait sources are heavily discouraged. Please de-clickbait titles if it needs to be submitted.
8. Submission statements of any length composed of your own thoughts inside the post text field are mandatory for any microblog posts, and are optional but recommended for article/image/video posts.
Community Resources:
We are Android girls*,
In our Lemmy.world.
The back is plastic,
It's fantastic.
*Well, not just girls: people of all gender identities are welcomed here.
Our Partner Communities:
founded 1 year ago
MODERATORS
Hello, and thank you for taking the time to compose this response.
I think that I may have conflated the choice of language with the choice of distribution. I believe the choice of language is independent of the choice to distribute apps as native or not, for at least Java because Java has solutions for AOT compilation not the least of which was actually used before in Android 5 according to another response, and it was used prior to Android 7 according to this resource.
For the sake of discussion, I propose that this existing AOT compiler for Android Java applications (used today in the hybrid solution) be run in its entirety on a server instead of on the user devices. I don't see a motivating reason to have the compiler on every user device to include a complex profile-guided optimization framework and hybrid JIT compiler (described in my third link in the original post) when we could ship the finished code and be done with it.
The benefit would be lower maintenance of the Android platform through a simpler design. (This benefit might shake out, but I get to that later.)
The migration process would consist of doing nothing for the typical app developer making this change quite cheap. The same languages would be supported as they are now. Indeed, this transition has already happened before and shows that this approach works, except with the build process happening on the device in earlier Android versions. I don't understand why Google did not go a step further and ship the binaries, instead choosing to take a step back and ship a JIT compiler with the AOT compiler. Why ship the intermediate bytecode representation and insist on a complex on-device build and optimization runtime?
From the responses that I have received so far, I think the true answer as to why distribution isn't native is likely composed of a combination of the following factors:
I'm sure that I'm making further assumptions, and surely there are oddball apps out there that really depend on having dynamic optimization to be performant, but I suspect these apps are in the minority. At a glance, the current solution seems too complicated, but I think understanding the history of the platform and the selection of devices that are supported today mostly answers my original question. Briefly, arm64 is absolutely not the end of the story even if it's listed as the supported CPU architecture, and officially committing to just one now and forever could come home to roost.
I think the main issue is who it'd be simpler for. Let's say that they switched to AOT compiling. That enables them to "simplify" the way Android works internally.
Who does that actually make things simpler for?
Literally ONE subteam of the Android team at Google. Nobody else.
It wouldn't make things any simpler for developers. In fact, it'd make things worse because AOT compilation is slower and doesn't allow things like hot-swapping code while your app is running - something you can do now with Java.
It wouldn't make things any simpler for OEMs. They don't have to worry about the Java runtime at all, they just worry about drivers.
It wouldn't make things any simpler for the other 99% of the Android team that builds new APIs, new drivers, etc.
Basically you're proposing a radical change that would make the platform worse for almost everyone, just so that one pretty small team at Google that builds the Java runtime portion of Android could make it a little simpler???
You say the current system seems "too complicated". I agree it's complex, but for a reason. Actually just about everything in tech is complex if you peek behind the curtain and learn how it works inside. The only difference here is that the code is open so anyone can see how it works. But for the most part these are just hidden details.
I guarantee that if you looked into how video frame compositing on Android works, or how low-latency audio works, or any of a hundred other things, you'd realize they're incredibly complex too - probably "too complicated" at first. But that complexity is for a reason.
QED, I think this response completely addresses my concerns. I often miss the social aspect of systems that involve people. I can't think of any further questions.
I reverse native binaries across a few different platforms for a living, but I'm just getting into Android. I will definitely take a look at those systems!