Comment Dubious choice of benchmarks (Score 2, Insightful) 677
Since registration is required to read the article, I have not read it. But given the title of the publication I was alert to the possibility of bias, and I think it's quite strongly present in the introduction. Java is the platform against which .Net will be measured for the forseable time and I think that the choice of benchmarks in Part 1 strongly favour .Net.
application invocation (time to load and execute)
It seems likely to me that the CLR will be be preloaded/vigorously cached by a Microsoft OS whereas the JVM is treated like any other application. Startup times will be skewed appropriately
algorithms and recursion (calculating Pi and Eratosthenes's sieve)
One of the small number of additional features of the CLR over the JVM is support for tail-end-recursive algorithms. This test will favour the CLR for the reason.
conversions (int to float, float to int, int to string, string to int)
A valid test but half useless. How much time is spent in an application casting from float to int or vice versa? Conversion between ints and strings is a valuable benchmark (XML based applications have to that often).
string comparison, string concatenation, string tokenization
Java has a weakness (actually it has had many) with its treatment of String handling. They are slow to manipulate and memory heavy. Further changes are being made in 1.5 (introduction of non-synchronized StringBuilder class). If the .Net libraries can't do better than the Java libraries then I'm appalled.
From the outside, this article just looks like another opportunity has been taken to falsely bash Java with .Net
application invocation (time to load and execute)
It seems likely to me that the CLR will be be preloaded/vigorously cached by a Microsoft OS whereas the JVM is treated like any other application. Startup times will be skewed appropriately
algorithms and recursion (calculating Pi and Eratosthenes's sieve)
One of the small number of additional features of the CLR over the JVM is support for tail-end-recursive algorithms. This test will favour the CLR for the reason.
conversions (int to float, float to int, int to string, string to int)
A valid test but half useless. How much time is spent in an application casting from float to int or vice versa? Conversion between ints and strings is a valuable benchmark (XML based applications have to that often).
string comparison, string concatenation, string tokenization
Java has a weakness (actually it has had many) with its treatment of String handling. They are slow to manipulate and memory heavy. Further changes are being made in 1.5 (introduction of non-synchronized StringBuilder class). If the
From the outside, this article just looks like another opportunity has been taken to falsely bash Java with
