Why Android went with Java?
-
Because Google likes lawsuits? ;-)
-
Have you tried asking Google that question? The people involved in the discussions that lead up to that decision work there for the biggest part I would assume.
-
Well, it is not Java as in Java. Android uses a Java-like language frontend, but uses a different, JVM-incompatible virtual machine backend.
They use an intermediate language / virtual machine for the same reason everyone does: portability and security.
And when it comes down to selecting a suitable frontend language, which is object-oriented, supports garbage collection, isn't maintained and used by your direct competitors and known by a widespread (entry-level) audience there is no way around Java.
-
[quote author="Seba84" date="1324290149"]Google chose to do a linux OS for phones that was done on C/C++. But for apps: Java. Why?[/quote]
I guess the same reason why IBM had to write Eclipse in Java: developers want to use what they (think they) know better. And Java is very popular language at the moment. It is far from being the best one, in my opinion, but is quite simple and comprehensive.
-
Its more than java; the entire toolkit is designed to fit the mindset of a web developer.
I used the toolkit for about 10 minutes prior to getting mad at it.
Happily I am now developing back on Qt / C++.
-bms
-
Thanks for the answers guys!
[quote author="fluca1978" date="1324314920"]
I guess the same reason why IBM had to write Eclipse in Java: developers want to use what they (think they) know better. And Java is very popular language at the moment. It is far from being the best one, in my opinion, but is quite simple and comprehensive.[/quote]I agree. Neither in my opinion.
[quote author="bms20" date="1324558915"]Its more than java; the entire toolkit is designed to fit the mindset of a web developer.
I used the toolkit for about 10 minutes prior to getting mad at it.
Happily I am now developing back on Qt / C++.
-bms[/quote]
I agree completelly, same problem with Java...
Do you think Android/Google ever thought of using Qt? And why they didn't? It is already available with most (or maybe all) of Linux distros...
-
[quote author="Seba84" date="1324734184"]
I agree completelly, same problem with Java...
Do you think Android/Google ever thought of using Qt? And why they didn't? It is already available with most (or maybe all) of Linux distros...[/quote]
I think they looked at ARM and decided "well no two arm SoCs are the same; this is pretty much like pc/workstations in the early 90s, lets use java". The fact that every ARM SoC has a god-damned different GCC version makes compiling C++ that much more difficult. That and the fact that most colleges now train their kids in Java* would cause google to view the language a fertile development platform.
Java may have also been a reaction to the perceived difficulties with programming in Objective-C; a requirement for the i products.
Also, Qt is(/was?) owned by Nokia, therefore, why touch a competitor's tools...
-bms
- I won't get started on java; I think Dijkstra said it all when he spoke about BASIC.
-
[quote author="bms20" date="1324558915"]Its more than java; the entire toolkit is designed to fit the mindset of a web developer.
I used the toolkit for about 10 minutes prior to getting mad at it.
Happily I am now developing back on Qt / C++.
-bms[/quote]
I feel the same about the Android Java api. Seems to be over engineered. But there is the Android NDK. Starting with Android 2.3 Applications can be written entirely in c++.
-
Hello Jayakrishnan,
Android says to don't this. Quoted from the "Android site":http://developer.android.com/sdk/ndk/overview.html:
When to Develop in Native Code
The NDK will not benefit most applications. As a developer, you need to balance its benefits against its drawbacks; notably, using native code does not result in an automatic performance increase, but always increases application complexity. In general, you should only use native code if it is essential to your application, not just because you prefer to program in C/C++.
Typical good candidates for the NDK are self-contained, CPU-intensive operations that don't allocate much memory, such as signal processing, physics simulation, and so on. Simply re-coding a method to run in C usually does not result in a large performance increase. When examining whether or not you should develop in native code, think about your requirements and see if the Android framework APIs provide the functionality that you need. The NDK can, however, can be an effective way to reuse a large corpus of existing C/C++ code.
Moreover, can you use Android UI libraries in C++?
-
[quote author="Seba84" date="1326643689"]Hello Jayakrishnan,
Android says to don't this. Quoted from the "Android site":http://developer.android.com/sdk/ndk/overview.html:
When to Develop in Native Code
The NDK will not benefit most applications. As a developer, you need to balance its benefits against its drawbacks; notably, using native code does not result in an automatic performance increase, but always increases application complexity. In general, you should only use native code if it is essential to your application, not just because you prefer to program in C/C++.
Typical good candidates for the NDK are self-contained, CPU-intensive operations that don't allocate much memory, such as signal processing, physics simulation, and so on. Simply re-coding a method to run in C usually does not result in a large performance increase. When examining whether or not you should develop in native code, think about your requirements and see if the Android framework APIs provide the functionality that you need. The NDK can, however, can be an effective way to reuse a large corpus of existing C/C++ code.
Moreover, can you use Android UI libraries in C++?
[/quote]I think the answer is in the Google qoute itself. Use it when it is really needed. But this is applicable for Java too. You shouldn't use Java where the NDK is more suitable. Graphics and multimedia applications are good candidates for NDK. Then we can reuse a lot of existing c\c++code. Regarding UI, from 2.3 NDK provides a native Actvity and the ability to create apps without Java. Also with each release, NDK is gaining more features. Using NDK is much like doing native linux programming and I love it. So I wonder what is the point in their ' don't use ' advise.
-
There are a lot of computer languages that carry an ideological chip on their shoulder.
Java is the worst of these languages - offering (as near as I can tell):
- a pretend world where memory and performance is of no concern
- a cargo-cult culture of gluing software together with Maven
- an undefined world of application failure by construction using Spring
- lots of delusional inexperienced developers preaching exactly how software development should be done; rather than ever taking the time to think about what the CPU may be executing.
Dijkstra's arguments against BASIC all apply to Java.
Sure I own a Samsung Galaxy S - but its embarrassingly unresponsive at 1ghz.
-bms
-
Java is much better suited to server side programming. c\c++ is better suited to programming resource constrained devices. There was always a huge difference in speed between native symbian and j2me applications. Despite earlier saying that they won't allow any native development Google was forced to provide the native development kit. You see all kinds of arguments like JIT, hotspot etc. But practically, Java desktop / mobile apps are sluggish compared to native apps.
-
[quote author="Jayakrishnan.M" date="1326958535"] But practically, Java desktop / mobile apps are sluggish compared to native apps.[/quote]
Its actually sluggish everywhere. Try starting eclipse, and compare that to starting qt-creator (or visual studio).
In a former life I was one (of two) developers working on a "search engine for mobile phones". The executives dreamed of taking on google; but with two "search engineers" it was more of a joke than reality; it did at least pay well.
Continuing with that joke, the entire system was written in Java.
That being said, the search engine was about 10x faster than lucene (at the time) in indexing and search. However, to serve a corpus of about 1 million web pages took an infrastructure of 24 top-end (in 2009) xeon-core i7 class machines with 36gb of ram each, divided into 10 shards 2x redundant (e.g. twenty machines). The front end machines (responsible for issuing queries to the shards) were configured in a pair for load balancing and 2x redundant (e.g. 4 machines).
This is what I learned after 18 months of fairly hard-core java work:
You will write your project at least three times:
First attempt will be "object-orientated" meaning it will use the keyword "class" and be made up of objects. This attempt will fail to meet performance goals by about a factor of two (even on top end hardware). More worryingly you'll be off by a factor of between 5 and 10 on memory, consuming far too much. You may, however, have proved your algorithms.
Second attempt will be a half-breed where you will try to do small steps to fix up the memory and performance problems. At least three weeks will be wasted doing this.
Third attempt will meet goals by: Storing all data in byte-backed-buffers that will be paged off of the disk. You will refer to structs using pointers into the byte-baked-buffer and numerical offsets. Your code will bear a lot of similarity to writing in Assembly (without macros), not C. You will encounter all of the problems of programming in assembly, without the luxury of the "struct" keyword from C.
One key thing to realize - all of the 2x redundancy (think of twice the price for your data center) had nothing to do with MTBF or high-availability (although that was aided). It had everything to do with the fact that a large garbage collection could stop a search worker for up to 1 minute. Yes, we had to use the stop-and-wait collector because none of the "more advanced ones" that Oracle were offering were reliable. Hence, queries were issued to both redundant pair simultaneously to avoid the latency.
So call me the java hater (I'll admit it). Every company I know of in Cambridge suffers with this language. They get suckered in via a promise of "cheap-experienced" developers straight out of college. It gives them easy startup and feel-good factor as they get their first hello-world window program up. They get stuck in and write a couple of hundred klocs and then realize that they are failing to meet performance goals. The question of "ditch java" may be discussed, but is never given serious thought. What emerges is a limp-forward strategy; they all become assembly-in-java programmers at some point.
Finally, I'll qualify this: C isn't the Pancea of languages; it has problems like all languages. As a professional developer the main barrier to finishing a job and meeting requirements is "code-understanding". What language you work in is important in how it aids your code-understanding. What I will emphatically state is that putting unnecessary barriers between the machine and the programmer (like java does) just makes hitting latency, memory, and throughput goals all the more difficult.
-bms
-
After reading this thread, I'm glad I started learning to program in C/C++. My experience is limited to MS Visual Studio 6 C++, then I found Qt, and never look back. I often read in the web how people enjoy developing with Qt, an so do I. In Visual Studio everything was terribly complicated and not very flexible. In the early versions of Android SDK I played a little with that, but it wasn't for me, I focused on Qt. Thank God now we have Necessitas, I will to try that one of this days, as has for IOS I just hope that some day a port will come. Anyway nice story on the post above, thanks for sharing.
-
[quote author="john_god" date="1327414406"]After reading this thread, I'm glad I started learning to program in C/C++. My experience is limited to MS Visual Studio 6 C++, then I found Qt, and never look back. I often read in the web how people enjoy developing with Qt, an so do I. In Visual Studio everything was terribly complicated and not very flexible. In the early versions of Android SDK I played a little with that, but it wasn't for me, I focused on Qt. Thank God now we have Necessitas, I will to try that one of this days, as has for IOS I just hope that some day a port will come. Anyway nice story on the post above, thanks for sharing.[/quote]
Please see this link
"http://developer.qt.nokia.com/forums/viewthread/12181/":http://developer.qt.nokia.com/forums/viewthread/12181/The iOS port should be available in near future. Qt should be available on Blackberry Qnx os too. So future of Qt on mobile looks good. Qt is already well established on desktop and embedded.
-
When iOS port will be available, Qt will be literally platform-independent!
I think anyway that all of this ports should be incorporated in Qt Creator. It would make life easier.
Seba84
-
They probably will, now that Open Governance is in place. But they must mature first, so that the whole official Qt package remains top-quality stuff.
They are even working on NaCL port! Pure beauty!
-
Very good! I hope this won't take a lot of time!
Sorry, but what is Open Governance?
-
See the "Qt Project":http://labs.qt.nokia.com/2011/09/12/qt-project/.
-
because java has strong GUI system than C/C++.