> There's nothing special in Java that doesn't exist in C++
Security as a language feature.

> A better model IMO is to use C++ and/or C for the raw engine and embed to or call
> from a very dynamic interpretted language
This approach has been used from times unknown. Letting C/C++ handle the rendering / physics while the developer can script away the entire game is the way to go. Graphics Engine / Physics engine / Particle engine come in as pluggable modules with a well exposed API. Look into games like 'Severance the Blade of Darkness or Freedom Force' which use Python as the scripting language.

> But not for the client end of a 3D FPS engine on PC/console with hot physics, graphics
> and the rest.
Agreed. Java has a long way to go.

>Why even try?
Because success comes to us only when we get used to failures.

> So to finish this off C/C++ or Java it does not really matter for most games.
It does matter. Every layer of abstraction has it's own price to pay. When we run C++ programs, what we run is raw machine code. When we run java programs, what we run is the JVM which loads the bytecode, converts it into machine code using JIT which is then executed.

>Unrelated; I actually prefer C# to Java,
Microsoft made a smart move by coming up with XNA in an attempt to push C# as a mainstream game programming language. Maybe java needs to do something along those lines...