The java specification states that the garbage collector is never guarenteed to run at any time during execution of the program.
This means that any heap allocated memory (e.g. any object you create) might never get deleted, depending on the VM implementation.
I think that fact alone is a good enough point to use a real language for writing games.

Also, ive speed tested newer versions of java, and in many cases it is exactly the same speed as C - but this is only on simple tests, like looping and adding numbers. Function calls, object creation, pointer usage, array usage all have much more overhead in java.
To everyone that says java is fast enough to make AAA titles, try it. No, really, i'd love to see you prove me wrong, but something tells me you wont. Java is just way too inefficient at managing every computer resource...

Quote:Original post by jwalsh
Java isnt used on XBox, Xbox360, or PS2 (though neither is C#)

I just wanted to clear up some misinformation located in this line. Obviously XBox and PS2 do not have support, but the XBox 360 currently has a CLR implementation and managed DirectX ( an internal Microsoft implementation and not yet released). It is actually one of the targetted platforms for future development work with the XBox 360.

Quote:Original post by Anonymous Poster
The java specification states that the garbage collector is never guarenteed to run at any time during execution of the program.
This means that any heap allocated memory (e.g. any object you create) might never get deleted, depending on the VM implementation.

So what? Why would you care if your objects get deleted?

Quote:
Also, ive speed tested newer versions of java, and in many cases it is exactly the same speed as C - but this is only on simple tests, like looping and adding numbers. Function calls, object creation, pointer usage, array usage all have much more overhead in java.

Take a look at this article:
http://www-128.ibm.com/developerworks/java/library/j-jtp09275.html

Quote:from the article
Pop quiz: Which language boasts faster raw allocation performance, the Java language, or C/C++? The answer may surprise you -- allocation in modern JVMs is far faster than the best performing malloc implementations. The common code path for new Object() in HotSpot 1.4.2 and later is approximately 10 machine instructions (data provided by Sun; see Resources), whereas the best performing malloc implementations in C require on average between 60 and 100 instructions per call (Detlefs, et. al.; see Resources). And allocation performance is not a trivial component of overall performance -- benchmarks show that many real-world C and C++ programs, such as Perl and Ghostscript, spend 20 to 30 percent of their total execution time in malloc and free -- far more than the allocation and garbage collection overhead of a healthy Java application (Zorn; see Resources).

Quote:from the article
But allocation is only half of memory management -- deallocation is the other half. It turns out that for most objects, the direct garbage collection cost is -- zero. This is because a copying collector does not need to visit or copy dead objects, only live ones. So objects that become garbage shortly after allocation contribute no workload to the collection cycle.

It turns out that the vast majority of objects in typical object-oriented programs (between 92 and 98 percent according to various studies) "die young," which means they become garbage shortly after they are allocated, often before the next garbage collection. (This property is called the generational hypothesis and has been empirically tested and found to be true for many object-oriented languages.) Therefore, not only is allocation fast, but for most objects, deallocation is free.

Quote:
Java is just way too inefficient at managing every computer resource...

So you believe most programmers can handle computer resources smarter than Java? Escape Analysis (Java 1.6) to the rescue:

Quote:from the article
JVMs are surprisingly good at figuring out things that we used to assume only the developer could know. By letting the JVM choose between stack allocation and heap allocation on a case-by-case basis, we can get the performance benefits of stack allocation without making the programmer agonize over whether to allocate on the stack or on the heap.