3 ms·

I'm not sure if the book covers this, but I'm more curious about technical details like why Java was chosen as the language and why Dalvik as the VM (I know, "i

I'm not sure if the book covers this, but I'm more curious about technical details like why Java was chosen as the language and why Dalvik as the VM (I know, "it wasn't the JDK/JRE", but then why not a different language?), and other interesting choices (Linux for the kernel, for example).

Zigurd 12y ago
I've read, though I can't remember where, that a number of languages were under consideration. But the Android team mostly came from Danger, and Danger used Java. So the Android team had considerable experience designing a Java VM for a device with very limited resources. Although Android never shipped on such a device, the design target was 200Mhz CPU, no GPU, and, IIRC, 128 or 256MB RAM. That's luxurious compared to a Danger Hiptop, which IIRC had only 32MB. If you look at how many VM instances get started when an Android boots, it's pretty amazing that it doesn't take 15 minutes. Also it enabled them to piggyback on a very mature toolchain by translating from Java bytecode to Dalvik bytecode as the last thing before packaging an app. At the time, XCode had nothing like the linting and refactoring Eclipse had. If they had a similar toolchain for Danger, that would be another reason to stick to Java.
- joezydeco 12y ago
  I played with a Sooner phone (the HTC development phone) and I remember it having 64MB of RAM.
- vetinari 12y ago
  The original G1 had 192 MB RAM total, i.e. including radio. For application system, 128 was available (including VRAM).
SomeCallMeTim 12y ago
I'm sure Java was chosen because it was the dominant smartphone programming language at a time. And not for any actual good reasons. And we (Android developers) still need to suffer through their poor initial choice of platform; things would be so much better if they exposed a C API as a first-class citizen of the OS, rather than making Java the only first-class way to access Android.
- joezydeco 12y ago
  BREW. Oh dear god.
- rifung 12y ago
  You have no idea how happy I am to no longer need to program for Android =D Sadly.. still programming in Java (most of the time).. but one step at a time I guess
- vetinari 12y ago
  The original Danger Hip-Top also used Java. Rubin had already experience with that. They removed the part that sucked hard (MIDP) and replaced with their own implementation (Dalvik). In 2009, I thought the same way as you do - that C API would be better. However, I was wrong - the Java/Dalvik as a first class is actually better, Google got the possibility to be CPU-architecture independent. Today, we have ARM, Intel, MIPS implementations, that are all first class citizens. Compare that to the failure of Windows-on-ARM. Yes, the Java language is nothing to write home about - but there is a lot of existing code written in it, so replacing that would be difficult. Designing another language that could use the same standard library, API semantics AND be effective on small devices is not that easy (for example, Scala and Clojure both bring their own large standard libraries, Clojure also runtime overhead, making them both unusable on small devices).
  - asveikau 12y ago
    > Compare that to the failure of Windows-on-ARM. I don't think that failure occurred due to anything other than mismanagement. The Win8 cycle produced many things: * An OS for desktop PCs * Under the hood improvements vs. Win7, like faster boot * A tablet UI * A tablet * A port of NT to ARM * A tablet based on the above which could only run code signed by Microsoft * An app store with a new set of APIs that nobody cares about In a weird attempt to distinguish all of these bullet points they muddied the message. What was Windows 8 exactly? They produced oddities like a Windows tablet that won't run Windows programs (not even after a recompile), and a tablet UI that ran on desktops. Imagine a world where they shipped some other combination of these bullet points. Example: A laptop running ARM and recompiled Win32 apps, with a UI that more resembles Windows 7. I'd argue (and argued at the time) that would be more successful than Windows RT.

Zigurd 12y ago

I've read, though I can't remember where, that a number of languages were under consideration. But the Android team mostly came from Danger, and Danger used Java. So the Android team had considerable experience designing a Java VM for a device with very limited resources. Although Android never shipped on such a device, the design target was 200Mhz CPU, no GPU, and, IIRC, 128 or 256MB RAM. That's luxurious compared to a Danger Hiptop, which IIRC had only 32MB. If you look at how many VM instances get started when an Android boots, it's pretty amazing that it doesn't take 15 minutes. Also it enabled them to piggyback on a very mature toolchain by translating from Java bytecode to Dalvik bytecode as the last thing before packaging an app. At the time, XCode had nothing like the linting and refactoring Eclipse had. If they had a similar toolchain for Danger, that would be another reason to stick to Java.

joezydeco 12y ago
I played with a Sooner phone (the HTC development phone) and I remember it having 64MB of RAM.
vetinari 12y ago
The original G1 had 192 MB RAM total, i.e. including radio. For application system, 128 was available (including VRAM).

SomeCallMeTim 12y ago

I'm sure Java was chosen because it was the dominant smartphone programming language at a time. And not for any actual good reasons. And we (Android developers) still need to suffer through their poor initial choice of platform; things would be so much better if they exposed a C API as a first-class citizen of the OS, rather than making Java the only first-class way to access Android.

joezydeco 12y ago
BREW. Oh dear god.
rifung 12y ago
You have no idea how happy I am to no longer need to program for Android =D Sadly.. still programming in Java (most of the time).. but one step at a time I guess
vetinari 12y ago
The original Danger Hip-Top also used Java. Rubin had already experience with that. They removed the part that sucked hard (MIDP) and replaced with their own implementation (Dalvik). In 2009, I thought the same way as you do - that C API would be better. However, I was wrong - the Java/Dalvik as a first class is actually better, Google got the possibility to be CPU-architecture independent. Today, we have ARM, Intel, MIPS implementations, that are all first class citizens. Compare that to the failure of Windows-on-ARM. Yes, the Java language is nothing to write home about - but there is a lot of existing code written in it, so replacing that would be difficult. Designing another language that could use the same standard library, API semantics AND be effective on small devices is not that easy (for example, Scala and Clojure both bring their own large standard libraries, Clojure also runtime overhead, making them both unusable on small devices).
- asveikau 12y ago
  > Compare that to the failure of Windows-on-ARM. I don't think that failure occurred due to anything other than mismanagement. The Win8 cycle produced many things: * An OS for desktop PCs * Under the hood improvements vs. Win7, like faster boot * A tablet UI * A tablet * A port of NT to ARM * A tablet based on the above which could only run code signed by Microsoft * An app store with a new set of APIs that nobody cares about In a weird attempt to distinguish all of these bullet points they muddied the message. What was Windows 8 exactly? They produced oddities like a Windows tablet that won't run Windows programs (not even after a recompile), and a tablet UI that ran on desktops. Imagine a world where they shipped some other combination of these bullet points. Example: A laptop running ARM and recompiled Win32 apps, with a UI that more resembles Windows 7. I'd argue (and argued at the time) that would be more successful than Windows RT.