Why does Android use Java?

Question

OK, this should really be asked to someone from Google, but I just want other opinion.

Even Android supports Native code applications, the main development tool is Java. But why? I mean, isn't it too slow to interpret code on a mobile device? when introducing Froyo, Google said that new JIT compiler can achieve 2-5 times faster applications. This means, that using Java over native code is 2-x times slower.

Yes, I know that using managed code applications is safer in terms of system stability, since virtual machine has better control of program, but still, this performance drop is huge, and I don´t see any point why to use it. Please tell me some good reason. Thanks.

Answer 1

First of all it's about the same thing will windows mobile or the iPhone, the .net framework needs its own VM as well as cocoa.

And even if the performance is not at the best, because it's an interpretation of byte code, android brings the entire java community as potential developers. More applications, more clients, etc.

To finish, no performance is not that bad, that's why java is used even on smaller devices (see JavaMe).

Answer 2

The new JIT is running the applications 2 - 5 times faster than the old dalvikVM (both JAVA). So comparison is not C over JAVA, but JIT over dalvikVM.

Answer 3

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

Answer 4

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.

Answer 5

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...

Answer 6

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.

Answer 7

Some points:

• java is a known language, developers know it and don't have to learn it

• its harder to shoot yourself with java than with c, c++ code since it has no pointer arithmetic

• it runs in a vm, so no need to recompile it for every phone out there and easy to secure

• large number of developement tools for java (see first)

• several mobile phones already used java me, so java was known in the industry

• the speed difference is not an issue for most applications, if it where you should code in assembly

Answer 8

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 optomize 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.

Answer 9

Large firms are eager to use open source communities to generate their own applications to fullfill their and the end users needs. Software costs dramatically drop with this strategy. But this idea has some problems; if you dont control the teams that are working on your system, can you trust them? If android supports usage of C++ in all means, i cant think what will be going on that devices. The weakest application that is used generally on that devices will show overall performance of google android. Also there is another big problem. Companies! Small companies that want to earn some money from mobile applications. They generally continue coding the application till it works. If it starts to work they stop. No fixes. This generates lots of buggy application. And noone will fix them.

Plus; lots of people that knows Java, many companies prefer Java, hardware and kernel based changes wont affect the applications because of the abstraction etc.

Answer 10

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.