Come on, do you seriously feel that the execution speed of a Java program is comparable with a native one ?
Yes, because the parts of any Java program that run frequently enough to be worth optimizing are translated into native code by the JIT compiler. You can see the generated assembly and everything. At that point, it will be comparable with native code because it is native code.
Execution speed (and memory usage) of a Java program will be worsened somewhat by its garbage collector, of course. That is a trade-off for the improved memory safety guarantees that a GC-mandatory environment makes possible. Most notably, buffer overflow vulnerabilities in a Java program are impossible, so finding remotely-exploitable bugs in a Java program is that much harder.
It's not much of a trade-off, though. Tons of research has been poured into making the GCs in the current HotSpot JVM fast, and it shows.
Can you ignore how huge is the CPU power needed for the Android UI to run smoothly ?
Yes, because it isn't huge. If it was, Android phones would have no battery life.
Anyway, Android has its own, shitty, pseudo-Java VM called Dalvik, and a newer, less-shitty, still-pseudo-Java VM called ART. Neither of these is even an actual JVM, let alone the only JVM.
Don't you know that the jvm is considered as one of the most unsafe and dangerous programs ?
Whoever told you that has a very incomplete understanding of the situation. Stop listening to that person.
Running arbitrary Java applets is unsafe, but that's got nothing to do with the JVM itself. You wouldn't run arbitrary C programs directly from web pages, either.