Slashdot Mirror

Do the graphics bother anybody else? It's the strangest thing... I keep thinking that they look almost identical to early episodes of Reboot and the prerendered sprites of Might & Magic VI (example). Despite them being fairly cutting edge graphics, my brain keeps telling me "This is so 1998."

Only in the most tenacious sense:

avsim.com

"Next urban legend says, that IL-2 is coded in Java. Again, this assumption is based on rumors only, and has no substance. Java is used in IL-2, but just in small part. C++ is mostly used in coding this baby."

rolemaker.dk

"Uses dirty Java by mixing Java with C++, such that logic and part of the game engine is in Java but all the graphics are in C++."

According to another writeup (which I've been unable to track down again), it essentially used a homebrew Java-based language internally for scripting the user interface and pilot AI. It sounded like there wasn't even a VM or anything along those lines involved.

Of course, it's easy to find fanboy sites breathlessly claiming it's "90% Java"...

Actually Sun should spend much more time reviewing the Java3D architecture. It is much slower that for example the GL4Java bindings (which should be available for pretty many platforms). I don't know if this has changed, but this information is based on this report.

Check out this

I read it just yesteday and must day that I'm impressed with all the information in this report. Certainly a good resource on this subject.

How is it "rigid"?

I read your story: 'There wasn't enough room for comments, so we hacked ...'. You then complain that your hack doesn't work.

Further, the current EDI networks are still more reliable and secure than web-based solutions. Many big-name companies don't want to switch until such issues are solved on the web.

Big companies can pay for a subscriber line to their suppliers and/or customers that circumvents the internet. Small companies just have to to take the risk I'm afraid.

Nope! XML takes up more bandwidth than some other solutions because it repeats field/tag-names for each record. I realize that this is generally not a problem, but it does show that you are wrong.

I don't see how this is related to translating. If there is a problem with bandwith, you can simply compress the XML. Do note that we are generally moving away from efficiency towards clarity and simplicity.

And how the heck does the VM contribute to "fast development" and "good features", and "big libraries"?

I wasn't simply talking about the benefits/downsides of a JVM (I never intended to narrow the discussion, the JVM vs P-code was just an example of Java not being incredibly revolutionary). Useful things are usually not revolutionary BTW. They evolve from useless revolutionary technology (which is too complex or slow to be useful). I do claim that all the features of the language (some of which are due to the VM) are good enough to offset the slowless.

I want to refer you to this excellent report on the performance of Java. Some highlights:

"Java has a strong reputation for being a slow language that cannot be seriously considered for real applications. It has not gotten this reputation by coincidence. If you are a C++ programmer then you were probably very tired of all those Java evangelists back in 1995 that claimed that Java was superior in every regard and that 100% pure Java was the best thing there was. They even sometimes claimed that it ran practically as fast as C++, and that any measured differences were insignificant. Chances are that you tried it back then, saw how awfully slow it ran, and then dismissed it as a web development toy and decided that the Java evangelists either was liars or fools. Fortunately, most the hype surrounding Java has since then died out and the compilers and virtual machines has improved significantly in meantime. I heard the same hyped arguments back then and originally dispelled the use of Java as anything but a web applet language, because of the many promises that was clearly not true. I did not return to Java until late in 1998. [...] As we will see in this chapter Java is in fact not as slow as its reputation claims; it all depends on how you use it." [page 32]

Sounds like he had thoughts similar to yours. He changed his mind though:

"One very important factor is the amount of tweaking that has been performed on the Java program. According to the conclusions of chapter 7, a non-tweaked program will be several factors slower than an equivalent C++ program. In my tests it was 2.5 to 4 times slower [on a modern JVM]. [...] However, if the Java program is tweaked (and the C++ program is tweaked too for fairness in comparison) this difference is reduced significantly. Many highly tweaked programs have in fact been shown to be able to run faster in Java than in C++. [...] Judging from the various benchmarks I would say that tweaked Java programs on the average runs 20-50% slower than tweaked C++ program" [page 34&35]

The writer also comments that tweaked code doesn't get the advantage of quick development (about a 30% productivity boost overall), but that will only be true for the 10% of critical code. Furthermore he points out that Swing is too slow. He also shows that JVM's are progressing quickly. A very good point is that Java is plagued by too many poor programmers because the language is easy to learn (the VB-curse). In the end he sees Java as a good option for some games.

Whatta brochure-head you are.

Yep, the kind of brochures with references and benchmarks. And sometimes they are graded at a university with an A+.

Should I put more credit in someone who critiques a language by attacking an article of a random Java supporter, complaining about several style issues, blaming the language for having flaws that are not explained (what is wrong with the reflection in Java?) and using sweeping statements that are unsupported by evidence: "Most heavy OO fans agree". He even attacks the language for being OO ("Java does not make doing procedural programming very easy.").

SOAP and WS is meant to replace non-remote API calls ???????

That might be a good idea (assuming we are talking about calling API's with a few calls only, not basic library-calls). Using GLUE you can reach 300,000 messages/second in the same application. It contains various optimizations for local use.

This is only one implementation of course. But it seems to be possible to get decent performance. I certainly won't dismiss it as a possibility beforehand.

How is it "rigid"?

I read your story: 'There wasn't enough room for comments, so we hacked ...'. You then complain that your hack doesn't work.

Further, the current EDI networks are still more reliable and secure than web-based solutions. Many big-name companies don't want to switch until such issues are solved on the web.

Big companies can pay for a subscriber line to their suppliers and/or customers that circumvents the internet. Small companies just have to to take the risk I'm afraid.

Nope! XML takes up more bandwidth than some other solutions because it repeats field/tag-names for each record. I realize that this is generally not a problem, but it does show that you are wrong.

I don't see how this is related to translating. If there is a problem with bandwith, you can simply compress the XML. Do note that we are generally moving away from efficiency towards clarity and simplicity.

And how the heck does the VM contribute to "fast development" and "good features", and "big libraries"?

I wasn't simply talking about the benefits/downsides of a JVM (I never intended to narrow the discussion, the JVM vs P-code was just an example of Java not being incredibly revolutionary). Useful things are usually not revolutionary BTW. They evolve from useless revolutionary technology (which is too complex or slow to be useful). I do claim that all the features of the language (some of which are due to the VM) are good enough to offset the slowless.

I want to refer you to this excellent report on the performance of Java. Some highlights:

"Java has a strong reputation for being a slow language that cannot be seriously considered for real applications. It has not gotten this reputation by coincidence. If you are a C++ programmer then you were probably very tired of all those Java evangelists back in 1995 that claimed that Java was superior in every regard and that 100% pure Java was the best thing there was. They even sometimes claimed that it ran practically as fast as C++, and that any measured differences were insignificant. Chances are that you tried it back then, saw how awfully slow it ran, and then dismissed it as a web development toy and decided that the Java evangelists either was liars or fools. Fortunately, most the hype surrounding Java has since then died out and the compilers and virtual machines has improved significantly in meantime. I heard the same hyped arguments back then and originally dispelled the use of Java as anything but a web applet language, because of the many promises that was clearly not true. I did not return to Java until late in 1998. [...] As we will see in this chapter Java is in fact not as slow as its reputation claims; it all depends on how you use it." [page 32]

Sounds like he had thoughts similar to yours. He changed his mind though:

"One very important factor is the amount of tweaking that has been performed on the Java program. According to the conclusions of chapter 7, a non-tweaked program will be several factors slower than an equivalent C++ program. In my tests it was 2.5 to 4 times slower [on a modern JVM]. [...] However, if the Java program is tweaked (and the C++ program is tweaked too for fairness in comparison) this difference is reduced significantly. Many highly tweaked programs have in fact been shown to be able to run faster in Java than in C++. [...] Judging from the various benchmarks I would say that tweaked Java programs on the average runs 20-50% slower than tweaked C++ program" [page 34&35]

The writer also comments that tweaked code doesn't get the advantage of quick development (about a 30% productivity boost overall), but that will only be true for the 10% of critical code. Furthermore he points out that Swing is too slow. He also shows that JVM's are progressing quickly. A very good point is that Java is plagued by too many poor programmers because the language is easy to learn (the VB-curse). In the end he sees Java as a good option for some games.

Whatta brochure-head you are.

Yep, the kind of brochures with references and benchmarks. And sometimes they are graded at a university with an A+.

Should I put more credit in someone who critiques a language by attacking an article of a random Java supporter, complaining about several style issues, blaming the language for having flaws that are not explained (what is wrong with the reflection in Java?) and using sweeping statements that are unsupported by evidence: "Most heavy OO fans agree". He even attacks the language for being OO ("Java does not make doing procedural programming very easy.").

SOAP and WS is meant to replace non-remote API calls ???????

That might be a good idea (assuming we are talking about calling API's with a few calls only, not basic library-calls). Using GLUE you can reach 300,000 messages/second in the same application. It contains various optimizations for local use.

This is only one implementation of course. But it seems to be possible to get decent performance. I certainly won't dismiss it as a possibility beforehand.

Of note was this article (actually this .pdf) that benchmarks several Java JIT environments, a Java native compiler, Visual C++ and Intel's C++ compiler. The optimized hardware accelerated OpenGL benchmark was nearly identical to the C++ version. Don't forget to read the errata which addresses his Java bias and other issues.

Regarding your Quake comment, I'll point out that Java was implemented for mod development for Quake 2. Definately not the game itself, but still it exists as a another example of how Java can be used in game development.

Of note was this article (actually this .pdf) that benchmarks several Java JIT environments, a Java native compiler, Visual C++ and Intel's C++ compiler. The optimized hardware accelerated OpenGL benchmark was nearly identical to the C++ version. Don't forget to read the errata which addresses his Java bias and other issues.

Regarding your Quake comment, I'll point out that Java was implemented for mod development for Quake 2. Definately not the game itself, but still it exists as a another example of how Java can be used in game development.

Of note was this article (actually this .pdf) that benchmarks several Java JIT environments, a Java native compiler, Visual C++ and Intel's C++ compiler. The optimized hardware accelerated OpenGL benchmark was nearly identical to the C++ version. Don't forget to read the errata which addresses his Java bias and other issues.

Regarding your Quake comment, I'll point out that Java was implemented for mod development for Quake 2. Definately not the game itself, but still it exists as a another example of how Java can be used in game development.

Quake [X] will never be written in Java.

Javalobby.com linked to this paper a few weeks ago that I think does a good job of addressing the performance issues in using java for game development. Here's one choice quote from John Carmack (page 75):

"We are still working with significant chunks of an existing code base. If I did want to go off and start fresh, I would likely try doing almost everything in Java."