I disagree

I disagree as well... From an language architecture standpoint, C and C++ are always going to be better than Java, simply because of Java's dependance on the Virtual Machine. While Java is always getting better, that layer will always cause Java to execute (for the most part) slower than any compiled C / C++ application.

For high-performance audio and video, C / C++ is the way to go.

Isnt the JVM itself written in C?

The Java specification doesn't mandate the JVM to be written in any particular language, but yes, it's almost always written in C like other VM's out there.

But you have got to realize that Java is an interpreted and not a compiled langauge. The java code is compiled by the 'javac' tool into a class file which is then loaded by the 'java' interpreter which interprets the bytecode and executes the given program. There is on the fly conversion from the java byte code(which is machine code to the java machine) to machine specific code.

At present, there is very slick chance of interpreted languages beating the performance offered by languages which are directly compiled to platform specific machine code like C and C++.

A rule of thumb: You don't gain abstractions for free.

Is .NETs CLI/CLR the same idea?

> Is .NETs CLI/CLR the same idea?
Since I am not involved with C# in any way, I would be in no position to answer that question but it seems that C# code is compiled to an intermediate byte code called IL which is converted on the fly into machine code.

Asking the same question in the C# forums would be more yieldy.

Yes, I'm pretty sure that that's the case. I know for a fact that .NET requires a VM and I do a little bit of Mono and a runtime VM is required to run any mono application.

The JVM can actually mean that your Java bytecode will run more highly optimised than any native compiled C or C++ code can.
The JIT compiler can provide runtime code optimisation which in a native compiled language is impossible.
As a result it can provide far more tuning of the machine instructions to the exact specs of the computer it is running on than is possible with a native compiled language.

The main area where code running inside a VM is slower (if the VM is good, and the JVMs provided by Sun and some others are very good) is in the loading time of the executable code, as that has to include final compilation into machine code which native compiled code doesn't need.
When finally executing, it will often run as fast as or faster than that native code.

This is shown time and again when doing realistic comparison between Java and native code.
If the application is shortlived, native code is faster (in extreme cases completing before the JVM has completed loading). For longlived applications though the Java code will execute at least as fast as comparable C++ code (if both are written to the same quality standards, rather than as is often the case with "tests" setting out to show that "Java is slow" the C++ code being highly optimised and the Java code deliberately poorly constructed).

And oh, Java is NOT an interpreted language.
It used to be, in the 1.0 release, a language that used interpreted bytecode.
Since the introduction of just in time compilers around 1997 it has been native compiled.
It's just that that native code is constructed on the fly during class loading rather than in advance during initial compilation.
Effectively the JVM is presented with what in C/C++ lingo would be object code, the code that's output by the compiler and presented to the linker.

Java itself is not slow, as others have already said it. But garbage collection (memory reorganization), which the JVM does from time to time can halt the execution of the program for some time. This manifests itself as a short lock in a real-time application like a 3D game. The Java program can be optimized, so that it produces no garbage, so no garbage collection will happen. Sadly this optimization is tedious work, just like optimizing C code. The best approach is using both Java and C, and linking the compiled C library dynamically to Java. If you are interested in a simple to learn Java game engine, check out jMonkeyEngine.

I can't see any gain in using Java over C++ in games unless it was always much faster in execution speed than C++, or provided some functionality or freedom that C++ doesn't; which it isn't, and doesn't. Like C++, Java can only ever hope to equal the speed of optimized machine code, and if it met the speed of machine code generated from C++ :- so what, it doesn't have the same existing 3rd party useful-for-games libs as C++ does at the moment, the standard library isn't as good ( I like simple and general rather than complex and all-encompasing ) all acccess to the OS/videocard is via a higher abstraction layer as exists in C++, garbage collection is a problem I suppose ( but the same strategy VeAr just outlined - minimizing collection, should be employed for C++ games anyway, i.e. minimizing allocations/deallocations on the heap during time-critical periods of runtime- even pre-arranging heap objects using estimated usage frequency/order, but you couldn't hope to do that in the Java as I know it ), the language architecture just isn't optimum anyway beyond prototyping - if I know the lifetime of an object, and that it should be stack allocated, I want to specify that explicitly in the code, not perhaps imply it in the design.

There's nothing special in Java that doesn't exist in C++, thread stuff is arguably made simpler across different platforms, and the general multiplatform aspect is a good thing - but this doesn't matter if you're releasing for a number of specific platforms. C++ can easily be written in a write once/compile anywhere way, and optimized for either platform at compilation - which is as good as compile once run anywhere in any case I can think of. The only other possible benefit for using one language over another is flexibility, and there's not much between the two, especially in terms of what most games require. 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, one that is significantly different to C++, either in terms of capabilities, application scope, or simplicity. Think Lisp, Prolog, Python, Lua or ECMAScript << none of these are 'C++ like', and all have different usefulness/simplicity/structure/writing-style scope. What's the scope of Java that falls outside that of C++???

There are certainly good places to use Java - server applications, mobile phone/web-based games, etc. But not for the client end of a 3D FPS engine on PC/console with hot physics, graphics and the rest. Why even try? You'd have little to rely on in terms of existing libraries, you wouldn't be able to hand optimize the code as far as you can in C++, you'd have to adopt OO religiously and be unable to use an 'objects are laid-out memory' approach anywhere, you'd have to wrestle with a garbage collector and have no idea where allocated objects 'go' rather than being able to just allocate in one place and remember to clean up; and for those setbacks, all you'd potentially gain is speed in that you'd only be writing network/thread code once rather than n times ( where n is the number of target platforms ), and a reflection system which honestly isn't very appropriate during realtime, nor particularly special.

C++ provides all a game developer really needs for the rawest part of the engine; perhaps a scripting framework ( inside or outside ) could augment that, but Java as the scripting language? Might aswell write the whole game in C++.