Ummm... Welcome to the 21st century, where the bottleneck in graphics is: the graphics card, your shaders (if you write the like crap, they'll run like crap), and memory I/O (between RAM and the video card). These days, the amount of graphical work done on the CPU is tiny.
Your point would be valid if it weren't for the fact there aren't any Java games that have graphics and performance comparable to a modern game written in a non-Java language (e.g., Crysis).
Spoken like a person who has no sense of style. Seriously though, while you are correct (Crysis in Java?) Minecraft has it's style for a reason but Java is able to do a lot nowadays. For example look at jMonkeyEngine and see what can be done with Java. This is without saying a single person will not be able to model, texture and animate things at Crysis level so that is most probably not going to happen and renders that point moot.
Here's a link to the only list I've found so far of commercial games made with Java:http://www.java-gami...hp/topic,3123.0
The latest game on the list, Tribal Trouble 2, has dated 3D graphics. Same situation with the rest of the games on the list too. I understand games made with Java have to work within Java's limitations but it's rather euphemistic
to explain the reason for the substandard graphics that's consistent on many Java games as simply a matter of differing style. Your reference jMonkeyEngine is a good example of Java trailing behind in the graphics department. Blocky, low poly, and pixelated graphics, seriously?
No it doesn't.
The Android NDK is a companion tool to the Android SDK that lets you build performance-critical portions of your apps in native code. It provides headers and libraries that allow you to build activities, handle user input, use hardware sensors, access application resources, and more, when programming in C or C++. If you write native code, your applications are still packaged into a .apk file and they still run inside of a virtual machine on the device. The fundamental Android application model does not change.
Most usages of C++ turn it into that anyway with smart pointers and things like that. Then you go even further with memory buckets etc. Until you basically end up writing verbose C#. If you don't do that with C++ your game or program is going to have so many possible ridiculous bugs and lots of undefined behaviour. Don't believe me? Look at this blog post by John Carmack.
John Carmack acknowledges problems, but what developer never encounters problems? What programming languages never have problems? Should a developer switch to another language simply because he found his current language too hard for him instead of working things out? Carmack never mentioned switching to Java anywhere in that blog post.
I'm not entirely discounting Java as a language for developing games, but with such a discouraging number of commercial games produced with Java, it doesn't support the opinion that Java is good for general game development especially if the developer wants to stay on the cutting edge.
I understand there are developers who feel a sense of romanticism for certain languages because of various reasons (e.g., it's their first language), but sentimentalism shouldn't taint the arguments of why languages are good or bad. Otherwise, why deny the shortcomings of a language in spite of evidence?