Why? Because you don't like Java? As a programmer you should write for the best tool for the job; databases mean SQL, build scripts mean python and perl, and Android programming means Java.
[quote name='Aliii' timestamp='1335024671' post='4933540']
Ive written a few little apps for android, but now I know that java is definitely not for me. I know that the best selling apps are usually 2D and all that, but Im mostly intrested in 3D or 2D physics, ...and to write that in java would be horror(for me at least).
I know there are tools for including native parts in the java code, but I dont know anything else about them. Is it hard to implement such tools or APIs? Do they produce more overhead than the speed I gain by writing in CPP? What parts of the application can I write in native?
Thanks very much!
[/quote]Java is JIT compiled to take best advantage of the hardware running it. It has been shown by quite a few major studies that Java is either on-par with C++ or better performing than C++. The only very rare exception is when you need to take advantage of some hardware-specific benefit that has no bytecode equivalent and the JIT compiler just cannot access. But Android doesn't have that problem since all the hardware out there runs java-accelerated chipsets.
Every device I'm aware of has chips that run Java bytecode directly. That means Java *IS* native code.
You can write whatever you want in whatever language you can find Android compilers for. There are quite a few languages to chose from. But don't expect to get better performance since Java *IS* the hardware native instruction set.
[/quote]
In regards to native execution of Java, I assume that you're referring to Jazelle? Two points:
1. Jazelle mode is no longer implemented fully on newer ARM processors, like those found on phones in the last 2 years. The only instructions it truly supports are to enter/exit Jazelle mode; no bytecode is executed natively any longer. They now rely on ThumbEE to make JIT faster.
2. Jazelle meant and continues to be absolutely useless for Android. Why? Because Android does not execute Java. It executes Dalvik bytecode: Dalvik bytecode is generated from JVM bytecode, but they are not equivalent, and Dalvik bytecode cannot be run by JVM or Jazelle.
There is no native hardware support for Java on any Android-powered device, because Android doesn't run Java, it runs Dalvik. The language it is written in is irrelevant, because it is converted later into an incompatible bytecode.
Past that, I used to work for one of the major Android device manufacturers. We preferred using native code for specific tasks, namely: graphics, physics, and other intensive operations. We had also started migrating a few major apps because of garbage collection calls; this is less of an issue post-Gingerbread, but on Froyo and before, the massive amount of boxing that Java required tripped the Dalvik GC all the time, causing stutters on the devices. Gingerbread alleviated this mostly but it still happens enough to be annoying. In regards to graphics, a HUGE reason you'd rather it be C or C++ is that OpenGL is implemented as a thin JNI wrapper. Every single GL call is a JNI call, which is slow regardless of the presence of the JIT. A single JNI call and then many native OpenGL calls is vastly faster than many JNI calls to native OpenGL calls.
In short, Java is not the native instruction set of any Android device, nor is even Dalvik. The native instruction set is ARM or ARM Thumb. The CPU nor any hardware on the device can natively execute either JVM Bytecode (which will not be present on the device anyways) or Dalvik bytecode. It is all executed via the Dalvik JIT on post-Froyo hardware, and the Dalvik interpreter on pre-Froyo hardware.
