Why does Android use Java? [closed]

Question

Some points:

1. Java is a known language, developers know it and don't have to learn it

2. it's harder to shoot yourself with Java than with C/C++ code since it has no pointer arithmetic

3. it runs in a VM, so no need to recompile it for every phone out there and easy to secure

4. large number of development tools for Java (see point 1)

5. several mobile phones already used Java ME, so Java was known in the industry

6. the speed difference is not an issue for most applications; if it was you should code in low-level language

On the byte-code level, Android doesn't use Java. The source is Java, but it doesn't use a JVM.

The improvement to system stability is very important on a device like a cell phone.

Security is even more important. The Android environment lets users run semi-trusted apps which could exploit the phone in truly unpleasant ways without excellent security. By running all apps in a virtual machine, you guarantee that no app can exploit the OS kernel unless there is a flaw in the VM implementation. The VM implementation, in turn, is presumably small and has a small, well-defined security surface.

Perhaps most important, when programs are compiled to code for a virtual machine, they do not have to be recompiled for new hardware. The market for phone chips is diverse and rapidly-changing, so that's a big deal.

Also, using Java makes it less likely that the apps people write will be exploitable themselves. No buffer-overruns, mistakes with pointers, etc...

Native code is not necessarily any faster than Java code. Where is your profile data showing that native code could run faster?

Why Java?

• Android runs on many different hardware platforms. You would need to compile and optimize your native code for each of these different platforms to see any real benefits.

• There are a large number of developers already proficient in Java.

• Java has huge open source support, with many libraries and tools available to make developers life easier.

• Java protects you from many of the problems inherent in native code, like memory leaks, bad pointer usage, etc.

• Java allows them to create sandbox applications, and create a better security model so that one bad App can't take down your entire OS.

First of all, according to Google, Android doesn't use Java. That's why Oracle is suing Google. Oracle claims that Android infringes on some Java technology, but Google says it's Dalvik.

Secondly, I haven't seen a Java byte code interpreter since 1995.

Can you back up your performance conjecture with some actual benchmarks? The scope of your presumptions don't seem justified given the inaccurate background information you provide.

Java has a pretty compelling argument for Google using it in Android: it has a huge base of developers. All these developers are (kind of) ready to develop for their mobile platform.

Keep in mind that, technically speaking, Android does not use pure Java.

As touched on elsewhere, the main issue is that Android is designed as a portable OS, to run on a wide variety of hardware. It's also building on a framework and language familiar to many existing mobile developers.

Finally, I would say it is a bet against the future - whatever performance issues exist will become irrelevant as hardware improves - equally by getting developers to code against an abstraction, Google can rip-out and change the underlying OS far more easily, than if developers were coding to the POSIX/Unix APIs.

For most applications the overhead of using a VM-based language over native is not significant (the bottleneck for apps consuming web services, like Twitter, is mostly networking). The Palm WebOS also demonstrates this - and that uses JavaScript rather than Java as the main language.

Given that almost all VMs JIT compile down to native code, raw code speed is often comparable with native speed. A lot of delays attributed to higher-level languages are less to do with the VM overhead than other factors (a complex object runtime, 'safety' checking memory access by doing bounds checking, etc).

Also remember that regardless of the language used to write an application, a lot of the actual work is done in lower level APIs. The top level language is often just chaining API calls together.

There are, of course, many exceptions to this rule - games, audio and graphics apps that push the limits of phone hardware. Even on the iOS, developers often drop down to C/C++ to get speed in these areas.