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.

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

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.

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.

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.

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.

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.

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]

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

---- SUPPORT REQUESTS VIA CHAT WILL BE IGNORED ----
If you have a question please use the forum so others can benefit from the solution in the future

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

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