Ok, há muita desinformação neste tópico.
Eu conheço o negócio do jogo extremamente bem, tendo estado nele por 25 anos. Eu também conheço muito bem o Java em jogos, tendo sido o evangelista técnico do Java Game da Sun e lecionando especialistas em programação de desempenho em Java.
Em termos de velocidade computacional, o Java supera o C ++ em muitos benchmarks de computação científica atuais. Você pode escrever código patológico em qualquer idioma que tenha um desempenho ruim, se quiser, mas no geral, eles estão no mesmo nível e há muito tempo.
Em termos de uso de memória, o Java tem alguma sobrecarga. HelloWorld é um programa 4K em java. Mas essa sobrecarga é bastante sem sentido nos sistemas atuais de vários GB. Finalmente, o Java tem mais de um tempo de inicialização. Eu não recomendaria usar o Java para utilitários de tempo de execução curtos, como comandos de linha de comando do Unix. Nesses casos, a inicialização dominará seu desempenho. Em um jogo, no entanto, é bastante insiginante.
O código do jogo Java corretamente escrito não sofre pausas no GC. Assim como o código C / C ++, requer algum gerenciamento de memória ativo, mas não o nível C / C ++. Contanto que você mantenha seu uso de memória para objetos de vida longa (persistir para um nível ou jogo inteiro) e objetos de vida muito curta (vetores e similares, passados e rapidamente destruídos após o cálculo), gc não deve ser um problema visível. p>
Em termos de acesso direto à memória, o Java tem isso há muito tempo; desde o Java 1.4 na forma de buffers de bytes diretos nativos. O bit twiddling em Java pode ser um pouco irritante devido à falta de tipos inteiros sem sinal, mas as rodadas de trabalho são todas bem conhecidas e não terrivelmente onerosas.
Embora seu verdadeiro Java nunca tenha uma ligação Direct3D, isso ocorre porque as tecnologias Java buscam a portabilidade. Ele tem DOIS enlaces OpenGL (JOGL e LWJGL) e ligação OpenAL (JOAL) e uma ligação de entrada portátil (JInput) que liga sob o capô a DirectInput no Windows, o HID Manager no OSX e uma ligação do Linux (esqueci quais). / p>
É verdade que nenhum mecanismo de jogo completo incluiu o Java, como o Unity, tem o C # e isso é uma fraqueza no espaço independente. Por outro lado, havia dois bons APIS de nível Scenegraph que eram totalmente portáveis em plataformas em Windows, OSX e Linux. Ambos escritos por Josh Slack, o primeiro foi chamado JMonkey engine e o segundo Ardor3D.
O primeiro pôster está correto ao afirmar que as duas maiores coisas que fizeram Java voltar ao desenvolvimento de jogos foram o preconceito e a portabilidade. Este último foi o maior problema. Embora você possa escrever um jogo Java e enviá-lo para o Windows, OSX e Linux, nunca houve uma VM de console. Isso ocorreu devido à total inépcia no gerenciamento médio da Sun. Os poucos de nós que trabalhavam com Java em jogos realmente tinham acordos com a Sony não menos que 3 vezes para obter uma VM em um Playstation e todas as 3 vezes que a gerência intermediária da Sun a matou.
Embora a Sun tenha flertado com tecnologias de clientes, o fato é que o gerenciamento da Sun nunca recebeu produtos de consumo. É por isso que o Java como uma linguagem de cliente da Sun nunca teve sucesso em nenhuma forma, e por que o Google e a Dalvik (a VM semelhante a Java do Android) tornaram o Java um sucesso de plataforma em qualquer lugar.
E é por isso que eu codifico jogos em C # hoje. Porque Mono foi onde a gerência da Sun se recusou.