When Bagley did the original shootout, he said it was "To learn and to have fun," adding that he would continue continue "as long as the fun holds out." This notion of enjoyment has been revived by the Debian Alioth update: 

"The project goals have not changed substantially since Doug's original project. This work is continuing so that we all can learn about new languages, compare them in various (possibly meaningless) ways, and most importantly, have some fun!"

"What you must realize is that C++ and Java have much different targets, it's rare that you will encounter a situation where both are equally suitable. No matter what, unless you forget to turn debug compile off, C++ will beat Java in real world situations on the performance front..."

"Try praising something else about Java...like its security, or ease of programming," Stuart continued.

GooberToo concurred. "The more I read the code, it sure is starting to look more and more like an apples and oranges comparison; which is usually what happens when people do Java benchmarks." And Iain too was unhappy: "Aside from perhaps demonstrating that you know Java far better than you know C++, I don't think these tests were a particularly useful exercise."

Others too felt that Lea's relative unfamiliarity with C++ compromised the exercise. "This article is completely useless and only shows the lack of understanding of C++ by the author," wrote Dr Valentin Samko. "This reminds me of a person who clamed that qbasic is faster than C++ because his program which outputs a few million blank lines works faster in qbasic than in C++."

Glen Low queried the shootout's methodology on a number of counts. Here is one:

"The small size of the programs are a definite advantage for Java's runtime optimizer. A run-time optimizer can't spend forever optimizing, but it has access to actual run-time data, AND can specialize its optimization for the specific processor. (G++, and most other C++ compilers, have flags to allow this as well.) Given the small size, a complete analysis of the program is possible in the limited time available, and given the other additional data, I would find it rather worrisome if Java didn't do better. I'm more sceptical with regards to real programs, however. If there really is one small critical loop, Java should win; that's not the case for most of my programs, however."

"I spent seven years doing C++ in a shrink wrap environment, and five doing Java. In my experience with real world apps, Java code gets done faster, works better out of the box, and is easier to maintain. Tricks like custom memory allocators and carefully crafted templates can make faster C++ code, but I reserve those for time critical parts of the program. Where I do not spend some programmer cycles profiling and optimizing, the two environments are pretty close.

Thus - if Java is producing code reasonably close or ahead in fairly straightforward usage, and the code gets written faster and more portably, then Java is a win for my work. I can always choose to use C++, assembly, or FORTRAN for the time critical routines, and then link in."

"As an experienced C++ developer (and Java as well) I only see that the C++ code is optimized for minimum performance. Especially the methodcall where the class has virtual constructors or destructors which is seldom useful and significantly hurts performance. Just because you can't turn this off in Java does not mean that you have to make it slow in C++."

"The comparison [Lea is] trying to make between C++ and Java is not particularly meaningful. At the end of the day, if a VM is faster, then there is nothing to stop you implementing a VM in C++ and running the 'C++ program' within that framework. What times would then be valid? The tools you are comparing are very different.
In addition, the C++ code is seriously sub-optimal. To take one example, the 'matrix.cpp' is definitely not written for speed. A general purpose C function is being used to repeatedly allocate rows, when a single large block of size 'mn' could have been used. For that matter, why is malloc( ) being used at all? (A custom memory manager optimised for small blocks could have been used instead - malloc( ) is slow.)

If you insist on writing simple C, then at least use memset( ) for the zeromatrix( ) function. Fast template matrix libraries exist for C++ - these could have been used instead - the result would have been shorter, clearer and considerably faster. Aside from perhaps demonstrating that you know Java far better than you know C++, I don't think these tests were a particularly useful exercise."

NotZed disagreed with the premise too, writing: "Java works well as a COBOL replacement, a backend application language for boring buisiness apps. That's what it should be benchmarked against. Comparing it to C is like comparing apples and oranges."

Chris countered: "Surely the benchmark is no less meaningful than when it was originally used to show C++ was faster than Java."  

And Christopher White commented:

"Thanks for the comparison Keith. I enjoyed reading your commentary.

Many people have stated in response to this article that Java, as everyone knows, is slow... This is certainly not the case. I am team leader of a Java development team. We have six applications in production on a certain open source application server. We have 1200 users of these applications. The applications are load-balanced over two machines (each machine : HP DL380 2*2.8GHz 2Gb RAM). We have on average 2% Cpu utilisation. Whilst this is of course just a subjective view of Java performance, I can say that we certainly do not have the impression that Java is at all slow.

I accept that for memory deallocation C++ can be tailored to the needs of the application at hand so it will be difficult to beat on this score, however one must remember that the just in time compiler compiles code into native machine language and that this compiler is very much optimized on a per platform basis so I don't see why C++ should produce naturally faster compiled code.

Whichever is faster, Java is easily fast enough for most applications and I strongly believe that the overhead in development time incurred by using C++ is rarely justified except in specialized applications such as driver or game coding."

For the moment let's give the last word to SB:

"Java and C++ are different languages, with different advantages/drawbacks, and different philosophies. My experience, from a large company that produces tons of software, is that performance always comes down to the quality of the developers, not the language itself. And we also found out that in today's world, most developers are only average, and this class of developers yields better results with Java than C++."