One of the major issues java is not ready for serious commercial game development is not being able get direct access to the display, sound and input hardware.

Although, I have read a few articles on how some big game companies are using java for their current games, but they are only using it as a scripting language. What I mean is they write all of the game engine code in asm/c/c++ but all of the game logic is written in java. There is a custom JNI interface that allows java to hook into the engine. I believe John Carmack considered this approach for Q3. Of course using a JNI interface defeats the cross platform benefit of Java.

Justin

quote:Original post by Jerry Lynn

The lack of multiple inheritance is not a language limitation. Almost all modern languages and underlying object systems do not allow multiple inheritance. Most OO analyst caution against using it as it has been shown to be a flawed concept.

I have to disagree and say that multiple inheritance solves certain problems far more elegantly than a single inheritance solution could. Interfaces can provide some of this functionality but not all.

quote:
Your first statement about optimized code development is fundamentally incorrect. It is possible to have the same code optimized for platform specific execution by a run-time complier.

No, there is a big difference here. The runtime optimizer, no matter how well it is done, is not going to have all the information that a developer has. As such, I could take advantage of specific ASM code that takes into account certain assumptions made by me, the developer, about the progression of my code. This will perhaps become even more of an issue when the new instruction sets become available, that place more of the burden of optimization on the developer and compiler. (This includes things such as choosing what data to precache, for example. I know what I want caching. An optimiser generally will not, unless it knows my game as well as I do.)

quote:
In fact, back end optimization systems have advantages over developers optimizing code because run-time optimization systems can take into account local variables such as memory availability on particular systems.

This is an advantage, but not necessarily as big as the disadvantage shown above. I can perform run-time optimization within my C/C++ code, to a degree, without losing the really low-level benefits.

quote:
Further, if you can have 95% optimized code or 100% optimized code that cost FIVE times as much which option do you think most business are going to choose?

5 times as much? That''s an arbitrary figure plucked from nowhere. C++ is almost as quick a language for developing in as Java if you use the provided string class and some socket library (which many developers will already have). The difference is that many developers, in the end, will -choose- to invest a lot of time in low-level optimisation, because that 5% extra performance is the difference between being "The fastest 3D game around today" and just another FPS.

quote:When it comes down to it, languages don’t become the dominant standard because they are fast. They become the standard because they increase developer productivity. With almost every language generation we have LOST performance. We lost performance when we went to C++ from Assembly. VB is MUCH slower than C++, and yet there are now 3 million VB developers building every thing from mission-critical business management software to games.

This is largely because (a) Visual C++ is crap for app development, and (b) MS have integrated Visual Basic code into Office etc. Not because the language is any good. The language is, quite frankly, awful

But, the point is that there are different tools for different needs. Visual Basic will never overtake C++ as the language of choice because of its disadvantages. Instead, it will faithfully serve its little niche, just like Cobol or Prolog.

quote:
Java has been documented to provide in some cases a five-fold increase in developer productivity over C++. As technology advances the performance issues will disappear and there will be no reason left to use C++ for the bulk of all development (this might come as a surprise but device drivers represent a small part of all development).

Ah, so that''s where the ''5x'' figure came from. It''s still utterly arbitrary. Performance issues will never disappear, as in the multimedia field there will always be a need to be 5% faster than the competition. When we''re all running in 3200x2800x32 bit colour at 100fps, someone else will want to do the same resolution at 120fps. If developers find Java to be 5% slower than C++, then they''re not going to bother moving over until all their competitors have. And their competitors will think the same thing, so it''ll most likely never happen.

Many games these days use their own byte-code language as opposed to straight C/C++. This provides them with many of the rapid-development issues of which you speak, except directly applicable to their problem domain, rather than the general purpose solution that is Java. Proprietary languages on top of low-level code is the way the industry will go, I think.