Why Android went with Java?
-
[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.
-
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!
-
See the "Qt Project":http://labs.qt.nokia.com/2011/09/12/qt-project/.
-
[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!!!
