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.
You are wrong on almost all counts.
1) The article was about the fact that Java is better than Obj-C for development because there are so many developers for it. The standard refrain for those users of Obj-C is that Java would be too slow for that.
2) Both Obj-C and Java do the optimization. If you look in the comments you can see where I removed the optimization in both. Java dropped from 73k to 61k and Obj-C dropped from 11k to 3.8k. So it went from 6x to 16x and Java was still competitive with C.
3) You even go on to help with my point by saying that this bears no relation to what goes on in a Cocoa program. You're right, in Cocoa programs you call Cocoa APIs. I'm sure that Obj-C is faster than Java doing that because Java has been crippled on Mac OS X by the fact that it is bridged to the core APIs. Fix that and you fix the whole problem.
So, since it was so hard to extract the real point of the article, I'll state it more plainly. It is stupid for Apple to use Objective-C. It is a dead language except on their platform and there are no developers for it. Their platform needs every developer it can find. Taking advantage of the Java VM is the best way for them to attract the greatest number of developers the fastest. All this microbenchmark shows is that Java is not behind in the speed race. I could point to further informal benchmarks that show the Java version of WO (5.x) is much faster than the Objective-C version, but I'm sure you would say that isn't a good benchmark either. Face it, Objective-C is a dead end for Apple and they need to get out of it as quickly as possible.
Just another point about microbenchmarks. In the land of XML documents, there are a lot of programs doing a lot of string compares at this particular point in history.
Firstly, I disagree with the premise that Apple "needs more developers". From where I'm looking, Apple gets more value out of its existing developers than you see on any other platform: there are a large number of very high quality (and often incredibly innovative) applications for the Mac at a reasonable cost.
I see very few desktop Java applications of similar quality.
If someone _wants_ to develop for the Mac, learning Objective C really isn't the hassle that it's made out to be. Mike Cannon-Brookes and I threw together an ObjC/Cocoa client for Confluence in under a day, based on a few tutorials and my "couple of days here or there experience of the language. Apart from the manual memory management, the language is really pretty easy to learn. All the tricky stuff is in the APIs, and you'd have to learn them regardless of the language you were accessing them from.
Apple can not rewrite Cocoa in Java, which is what they'd need to do. This isn't a question of choice, but one of necessity. It would literally set them back several years _before_ square one (remember, they inherited most of Cocoa from NeXTSTEP), just as OS X is reaching a pretty good level of useability, reliability and efficiency. It'd also orphan all their existing developers, which would kill the platform stone dead.
If Apple want to see a way ahead, I'd be more likely to see it in skipping Java (whose static typing makes it a bad fit for the Cocoa framework anyway), and going straight to Python. Which may already be their strategy - I'm seeing a lot of mentions of frameworks having Python bindings lately.
Also, as a nitpick, in the land of XML documents you'd use libxml2, which smokes pretty much every parser in every other language: http://xmlbench.sourceforge.net/results/benchmark200402/
> It is stupid for Apple to use Objective-C.
Ah! Always good to see a Java advocate in full-flight.
Alan: Stop trolling my blog :P
Although in one sense, it's ironic. Now that Java is optimised enough to compete with compiled languages on performance, it's like watching the class weakling go through a growth spurt and suddenly realise he can bully the smaller kids.
I agree Objective-C is easy to learn. But I still contend that Apple shouldn't half-heartedly support Java the way they do now. If its going to be in IB, for example, it should as expressive and stable as the alternative.
As for what actual language is used, I don't really care as long as it runs on the Java VM. If you want to use a loosely typed language like Python or Groovy, more power to you. But they can support a lot more languages on the Java VM than writing bindings for every different VM out there. BTW, Python users will probably be yelling bloody murder as well when they find that they are shut out from some features -- important features -- of the platform. And I seriously doubt using libxml2 through the Cocoa bindings is nearly as good as using it from C, and even worse when you use it through yet another layer if you call if from Java.
I firmly believe that Cocoa is the best framework out there, I also think that the Java VM is the best way to run programs. I just want to use them both at the same time without taking such a stability, accessibility and performance hit. And in the end, if Apple ever did have to change architectures again, they could do it without it being such a nightmare.
Sam: It's almost impossible for the dynamic languages to be "left behind" in the same way Java can, because they have the advantage of not needing concrete interface definitions or pre-defined object translations in the bridge.
I can't vouch for how PyObjC does it, but Ruby's dynamic typing means you can pull _any_ object from the Objective-C side and treat it as a Ruby object without having to assign it a concrete type or set of methods. There's basically one proxy class for all ObjC classes, with a "method_missing" method that acts as the bridge. (There are a few complications, like accessing functions that aren't bound to objects, and a special protocol for overriding inherited ObjC methods from a Ruby class, but they all seem to be worked out quite well).
This is a massive advantage over maintaining a Java bridge, where each ObjC class needs to be carefully assigned its own concrete Java class so that Java can enforce type-safety.
slightly off topic - i go back tomorrow, and i probably won't have time to meet you for drinks. not with my mother around anyway.
if u ever come to singapore - give me a holler.
"I can't vouch for how PyObjC does it, but Ruby's dynamic typing means you can pull _any_ object from the Objective-C side and treat it as a Ruby object without having to assign it a concrete type or set of methods. There's basically one proxy class for all ObjC classes, with a "method_missing" method that acts as the bridge."
I work on language bindings for the KDE project - wrapping the C++ Qt/KDE api. We have a language independent library called SMOKE short for 'Scripting Meta Object Kompiler Engine'. This adds a complete dynamic introspection to these normally fairly static C++ libraries, and allows a method to be looked up at runtime from its name and arg types. Arguments can be marshalled from the target language onto a common C++ stack type, and then the C++ method invoked.
I've used this library for the ruby bindings, QtRuby and Korundum; the way they work is to use method_missing() in exactly the same way you describe for Cocoa/Objective-C. The PerlQt and PerlKDE bindings also use SMOKE via perl's autoload feature.
The SMOKE library is autogenerated as part of the kdebindings cvs module's configuration, and so they are easy to maintain.
They can be used from java, but you need to generate the .java sources for the api using Dynamic proxies to do the job of funnelling all the java method calls into a single Proxy.invoke() invocation - in much the same way as several AOP implementations use 'interceptors'. There is more maintenance overhead than a completely dynamic language, but the java code is still autogenerated.
You guys are arguing about a dead platform.
(Heh - just kidding. But it is getting pretty religious in here.)
I'm not sure why you say the java string comparison is an identity check, it uses compareTo() which cycles through every character, addresses aren't compared at any point in String.compareTo() (although maybe a quick address check would make sense).
It is confusing! Obj-C is a _nice_ language, say some. And Jave to, say others. Both are true. But the important part is 'What's nice'?
The number of users/developers isn't a measurement for it. Otherwice MS would surely win:-(.
Personally, I like Obj-C while is is easy (for C programmers) and hase good OO. Jave is a kind of bug-fix language for C++. It surely is better then C++. And most Jave-programmers will are there language is better the C++. 10 years ago, the C++-people had won. In 10 years ...
But is Obj-C 'nicer' because I use it?
Yes, it's for me; but that doesn't count.
The same aplies to is Language_1 better the L_2? Yes, for some!
But don't assume it's bettyer for all!
--ALbert
Is there some reason why Apple can't add full garbage collection to Objective-C?