It all started with Sam Pullara claiming that:
- Java method calls and field accesses are faster than their Objective-C counterparts, therefore
- Apple should replace Objective-C with Java as the primary development platform on OS X.
Note, that's all the benchmark really tests: the "string comparisons" devolve down to identity equality in both cases. Also note that the "straight C vs Java" comparison later in the article is ridiculously biased: it's comparing an identity check on Java's side with a full string comparison on C's side1, and C still wins on my machine2. (I wrote my own strcmp that does an identity check first. With that, the C version suddenly wins over Java by a factor of ten2).
All of which means precisely nothing. The benchmark bears about as much relation to what really happens in a Cocoa program as, well, some really great analogy that I can't think of right now because it's too early in the morning. Micro-benchmarks are always so ridiculously contrived that they only serve to throw around confusion and mindless advocacy3.
Apple won't switch to Java as the primary development platform for OS X. They can't without rewriting most of the OS. Calling for them to do so on the basis of a benchmark that doesn't even prove what it sets out to prove is just silly.
Addendum: The next version of OS X is going to be called Tiger. Oh how wonderful. Now I'm going to be stuck asking things like "So, will Tiger be able to run Tiger?"
1 One of Java's smart optimisations is that it's actually quite hard to build two identical strings that aren't identical objects, or at least that don't share an identical char[] pointer and offsets. The JVM is quite willing to say "Oooh, that looks like something I've already got in the constant pool. I'll use that one instead."
2 if you compile with -fast -mcpu=G4.
3 If the numbers had been reversed, the entire Java community would be crying FUD.
