Why Android used Java concept instead of D language or C or C++? But Chromium web browser is in C++, its very complicated match

Question

Android is 32-bit ARM. wiki

Description:

1) So, 32/64 or 8/12/16 Bit compiler is available with D language if not it can be builded by a compiler, if i am not wrong?

2) Linux standard kernel: Libraries written in C and other languages can be compiled to ARM wtih D language i believe, not only D language also possible with C/C++.

According to Android wiki information starts my confusion:

• wiki: Modified version of the Linux kernel (its not linux but its modified linux, beause hardware compatibility? So i cant use RPM packaging? Because its not standard linux anymore?)

• wiki: While most Android applications are written in Java, there is no Java Virtual Machine in the platform and Java byte code is not executed. Java classes are compiled into Dalvik executables and run on the Dalvik virtual machine. Dalvik is a specialized virtual machine designed specifically for Android and optimized for battery-powered mobile devices with limited memory and CPU. J2ME support can be provided via third-party-applications.

Question: Why just Android is not written either with D or C/C++ languages? Instead of dealing with all those mess, this is the only company proved that Bigtable they needed (world cant solve there issue yet) and Mobile platform also requires changes such as Android? Whats wrong with iPhone/Nokia implementation then?

Question: Why Android dont run JVM but they build a Java concept does alternative JVM processing, instead of doing same such as MeeGo or others. Is that a marketing terms or is that a technical term? Can it not be written in C/C++ or D language only the whole Android? Instead of involving Java concept or Mess concepts?

if yes then Chromium-web browser why they used again C++? Why not just followed Java also for Chromium-web?

Its all about to learn how its getting used in practical life, to me again, its just to know why they did such mess for Android? Are we then learning programming languages in University wrong way (knowing later, oh Big Google just used Java for Android) ?

Thanks in advance, for your valuable advise on this.

Solution 1

Why just Android is not written either with D or C/C++ languages?

Because none of them is a fully managed language. D is garbage collected, but you can also do manual memory management ... with all of the risks that that entails.

Also, because starting from a Java base (in the form of Apache Harmony, etc) meant that:

• Java developers would be able to transition to Android, and
• there would be less for the Android development team to implement.

However, as @Marchy points out, it wasn't Google that made the original decision:

"... Google didn't BUILD Android. [Android Inc] was a startup they bought, and as a startup you use whatever is out there and optimize to gain momentum FAST and with VERY limited resources. ..."

Though obviously Google did have a hand, since (according to Wikipedia) Google helped finance Android Inc prior to the buyout.

Why Android dont run JVM but they build a Java concept does alternative JVM processing.

Ultimately, because the restrictions that Sun / Oracle places on the Java language and platform would have made it impossible to innovate in the way Google has done with Android. Specifically, Sun / Oracle won't license vendors to implement Java SE on mobile platforms.

Are we then learning programming languages in University wrong way.

Maybe you did!!

But when I learned programming at University, it was in the full knowledge that I'd never use some of the languages I was taught about. For instance, I've never used Algol-60, Simula-67, SNOBOL or CDC assembly language since. But that did not invalidate the reasons that they were taught, or the valuable lessons I gained in learning them.

Solution 2

I'd guess it's because a lot of programmers are familiar with Java and Java, for all its faults as a language, has excellent library and tool support. Also, the layer of VM indirection prevents the apps from being too tightly coupled to the hardware.

Solution 3

There is a lot of Java programmers, a whole ecosystem to build upon. Much more than D :p An OS running most of the programs for it on a virtual machine have nice advantages for security (http://en.wikipedia.org/wiki/Language-based_system). But doing some exception for a very important application, from user point of view, can help performance. The choice of a specific JVM, it seems to be clear, it's to have something adapted to typical embedded resources. I think Google choices are quite pragmatic in that regard.

For the (rant on ?) teaching of languages at the university, I don't think it's about learning the latest fashionable language. It's about learning to learn computer related technologies, such as programming languages. The concepts did not changed much since, say 1960, 1970, although that ok, their implementation is different.

Comments

[Joachim Sauer]

This looks like a rant to me.

[Tamás Szelei]

There are so many misinformed statements in this question, that I wouldn't know where to start.

[Admin]

True, when you say managed language. The best one is www.purebasic.com alas they are not the Native languages. :)

[Stephen C]

Yea ... but the real issue is that programming language decisions are (generally speaking) made based on more important criteria than the purely technical merits of the respective languages.

[Marchy]

Guys don't forget that Google didn't BUILD Android. It was a startup they bought, and as a startup you use whatever is out there and optimize to gain momentum FAST and with VERY limited resources. From an architectural perspective Android has many significant core mistakes, such as an amateur presentation framework that severely limits UI complexity through it's lack of MVC (and its single running activity ASSUMPTION). No experienced presentation framework architect would have ever allowed such a limitation - the result is apps that CANNOT achieve UX comparable to platforms such as iOS.

[Stephen C]

@Marchy - On the other hand, those mistakes probably haven't made any difference to the success of Android. Technical merits / failings in the underlying software rarely impact on market success ... provided that end-user usability issues have been handled well.

[ARF]

One big point that they chose Java is tools. Java has tons of tools that are already proven to work, Eclipse being the most important of them for the Android team. Another point is that what the Android team do was build a bytecode translator (JVM bytecode to Dalvik bytecode) so the Android team also used traditional Java compilers only taking their output and translating it.