Okay, theres a lot of misinformation in this thread.
I know the game business extremely well, having been in it for 25 years. I also know Java in games extremely well having been Sun's Java Game technical evangelist and lecturing Java performance programming expert.
In terms of computational speed, Java beats C++ in many scientific computing benchmarks today. You can write pathological code in either language that performs badly if you want to, but over-all, they are at par and have been for a long time.
In terms of memory usage, Java does have some over-head. HelloWorld is a 4K program in java. But that overhead is pretty meaningless in todays multi GB systems. Finally, Java does have more of a startup time. I would not recommend using Java for short run-time utilities like Unix command line commands. In those cases startup will dominate your performance. In a game however, its fairly insiginficant.
Properly written Java game code does not suffer GC pauses. Just like C/C++ code, it does require some active memory management but not to the level C/C++ does. As long as you keep your memory usage to either long lived objects (persist for an entire level or game) and very short lived objects (vectors and such, passed around and quickly destroyed after calculation) gc should not be a visible issue.
In terms of direct memory access, Java has had that for a LONG time; since Java 1.4 in the form of Native Direct Byte Buffers. Bit twiddling in Java can be slightly annoying due to the lack of unsigned integer types but the work rounds are all well known and not terribly onerous.
While its true Java has never had a Direct3D binding, thats because Java technologies strive for portability. It has TWO OpenGL bindings (JOGL and LWJGL) and OpenAL binding (JOAL) and a portable input binding (JInput) that binds under the hood to DirectInput on Windows, HID Manager on OSX, and a Linux binding (I forget which).
Its true that no complete game engines have featured Java the way, say Unity, has featured C# and that is a weakness in the independent space. On the other hand, there were two good Scenegraph level APIS that were totally platform portable across Windows, OSX and Linux. Both written by Josh Slack, the first was called JMonkey engine and the second Ardor3D.
The top poster is correct that the two biggest things that held Java back in game development were prejudice and portability. The latter was the biggest issue. Although you could write a Java game and ship it on Windows, OSX and Linux, there was never a console VM. This was due to total ineptitude in Sun middle management. The few of us working on Java in games actually had deals with Sony no less then 3 times to get a VM on a Playstation and all 3 times Sun middle management killed it.
While Sun flirted with client technologies, the fact of the matter is that Sun management never got consumer products. Thats why Java as a client language from Sun never succeeded in any form, and why it took Google and Dalvik (the Android java-like VM) to make Java a platform success anywhere.
And thats why I code games in C# today. Because Mono went where Sun management refused to.