Why Android went with Java?
-
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++.
-
what is the difference between throws and throw. i have read from internet but point is not clear to me.
-
[quote author="mk12345" date="1383736748"]what is the difference between throws and throw. i have read from internet but point is not clear to me.[/quote]
The "s" at the end of the word. What are you really asking about, and why in this thread?
-
[quote author="mk12345" date="1383736748"]what is the difference between throws and throw. i have read from internet but point is not clear to me.[/quote]
throws specifies that the class may throw an exception which needs to be handled somewhere in the call stack when using this class/method.And throw actually raises the exception upwards the call-stack, which needs to be handled anywhere and if not the application crashes.
But as sierdzio said, this is not the place to ask this here.
-
It's two year's since I opened this thread and much has changed. I see that the last version of Qt Creator is Android compatible (I suppose that Necessitas is inside it). I didn't test it, are the results looking good? Is it buggy?
In the time being, I have learnt Java and the Android SDK package. A piece of cake coming from C/C++. The conclusion from the experience was: better stick to C/C++.
-
"because java has strong GUI system than C/C++."
I hope this was posted in jest...but it is typical of the misunderstanding of what is being discussed here, by MOST Java adherents.
C/C++ vs Java is NOT a war or a comparison of "who has the better GUI system"--THAT is irrelevant and a non-sequitur, as I'm sure most on this forum already realize. Language features and drawbacks have very little to do with the GUI that serves as a presentation layer.
The original idea behind Java, to obscure the HW and provide a VM orchestrated sandbox comes with so many penalties (in speed, obfuscation, control, etc, etc), we as programmers and engineers are always trying to play catchup...
In terms of Android, it's amazing that this Linux/JVM/User code scheme is workable AT ALL. There is so much layering and object instantiation that, indeed, a 1/2/4 core 1+Ghz platform still seems sluggish! And to top it off, we have to dance around a blocking GC in the VM!
There is a reason why C++ is NOT favored in OS and limited resource scenarios--and the same can be said for Java, in terms of the penalties one incurs with OO in general.
Even Google realizes this, but instead of changing gears, back to native code, they come out with yet another VM (ART) to patch up the scheme, and try to make all this gobbledegook a little faster....amazing!!!
-
IBM wrote Eclipse ?! that is awesome !!!!