Back in 2008 when Android phones were first released, there was a blog post[1] about Dalvik's (lack of) performance and I decided to try it on my Sony Ericsson K800i[2], which was released in 2006 and ran Java ME apps (and miraculously even had an "app store" even though Apple wouldn't invent it until 2008).
The microbenchmark in the blog post ran in 922 milliseconds on the Google G1 (a.k.a. HTC Dream), or 520 without the assignment in the loop. On my K800i the corresponding numbers were 190–220 ms and 135–165 ms – although I had to scale the size of the buffer down from 1228800 to 1100000 elements due to lack of memory, but scaling the results up by that factor the K800i was still 3–4 times as fast as the G1.
Hardware-wise the G1 should have been much faster. It had an ARM11 at 528 MHz and the K800i had (I think) an ARM9 at somewhere around or below 200 MHz.
Hey, a fellow K800i owner! I loved that phone, used to run Gmail on it (J2ME app). For its time it also had a pretty good camera. As far as I remember it didn't have a headphone jack though, just some weird proprietary headphones.
Every feature phone on the planet used to run Java ME without any problem. Dalvik may have had some optimisations, but to claim Java would have run "crazy slow" is unlikely to be the reason Google chose the implement their own VM.
JavaME was a total disaster of incompatibilities, lack of any useful API and broken platform support.
The fact that you can use a lot of standard Java libs with Android was and is a huge boon that makes development significantly easier than the hell that was JavaMe.
I guess you never had the fun to port Android code among OEMs, using OEM specific SDKs for specific features like real time audio, or work around firmware bugs specially on Samsung devices.
Android fragmentation is no different than J2ME used to be.
> Android fragmentation is no different than J2ME used to be
That has to be hyperbole: no one who ported J2ME apps would say what you did with a straight face. Even a run-of-the-mill app with no esoteric features would need to be ported because Nokia's methods had different signatures to SonyEricsson's for text fucking rendering, because why not. The entirety of J2ME an "OEM specific SDK" This is before considering MIDP, CLDC versions and goddamn model-specific processor and memory differences. "Android fragmentation is no different than J2ME used to be" my ass.
There was this thing called LWUIT and Sony supported Nokia extensions.
> no one who ported J2ME apps would say what you did with a straight face.
> This is before considering MIDP, CLDC versions and goddamn model-specific processor and memory differences. "Android fragmentation is no different than J2ME used to be" my ass.
How is Android any different? Should I start listing differences among devices here?
> Android fragmentation is no different than J2ME used to be.
This is a huge overstatement. J2ME was fragmented in things like basic UI with no tooling to handle it. In Android you really need to dig into hardware-specific funcionality (or really really mess up UI design) to be severely affected by the fragmentation.
No, Android became popular due to the Google loving hipsters that believed in FOSS and AOSP, and OEMs that just love getting an OS for free with almost no strings attached.
Every other commercial Java vendor in this planet doesn't have any issue using standard Java tools, compiling with Java licenses and deliver JVMs able to run in embedded devices with soft and hard real time constraints.
Google for all their might is a special snowflake not able to do what the rest of the Java world is capable of.
This sounds strange. Seems Next you will start claiming that Oracle DB is popular because Oracle loving hipsters like paying for heavy licensing fee and support and not because it is high performance DB for critical enterprise requirements.
The microbenchmark in the blog post ran in 922 milliseconds on the Google G1 (a.k.a. HTC Dream), or 520 without the assignment in the loop. On my K800i the corresponding numbers were 190–220 ms and 135–165 ms – although I had to scale the size of the buffer down from 1228800 to 1100000 elements due to lack of memory, but scaling the results up by that factor the K800i was still 3–4 times as fast as the G1.
Hardware-wise the G1 should have been much faster. It had an ARM11 at 528 MHz and the K800i had (I think) an ARM9 at somewhere around or below 200 MHz.
[1] http://web.archive.org/web/20091123074004/http://occipital.c...
[2] https://en.wikipedia.org/wiki/Sony_Ericsson_K800i