Hi, thanks for the responses. I've been a bit busy so sorry if I'm a bit late with this.

Jim: I appreciate your points though I think you are reading a bit too much into my motivations. I'm not really sulking about the loss (I had time enough back then to do so) so much as trying to show some of the factors which led to Sun's failure on the desktop and that much of that was in their control. I'm not sure where you are going with your marketing point. This was internal politics and it didn't matter how it was marketed. The mere fact that it was not their (JavaSoft's) idea cemented the decision. The main thing I am lamenting now is that my Sun stock is still stuck in single digits.

And things are much better now. These better ideas still exist and have been expanded upon in the Cocoa frameworks which I have been happily using since Apple revived them by buying NeXT. I think the quality of the apps built on the respective frameworks tells a lot of the story.

Also, I don't hate Java (not that you implied that at all; just trying to head off any such notions). I have been coding servers in Java for quite a number of years and Objective-C could learn a few things from Java on the language level. I just feel that the frameworks leave much to be desired when it comes to GUIs.

Ulrich: There are significant differences in how they operate. They are not items that appear on a check list. Hopefully, we can go beyond the notion that having the same list of features somehow makes them equivalent. Execution is everything. Also, read Jens Alfke's article (it is linked up top).

A quick example of how they fundamentally differ: Sun avoids dynamism. Though it can be achieved via reflection in Java, they avoid it at all costs. One of the areas where this becomes apparent is the huge class bloat when using Java. You end up coding tons of "glue" classes just to connect objects since you are stuck with a very specific method signature/interface. Inner/anonymous classes make it a tad more palatable but it's still tedious. A whole class just to have one method call another method on another object. To me, that sounds like a workaround for a bad decision. Compare that to the use of selectors (method pointers for those that don't know Objective-C) and you can see how cumbersome the Swing way is.

Frameworks and APIs should not just be ways to access functionality. "Adequate" is not enough. The framework should inspire, encourage the good things and discourage the bad. It should allow you to express what you want to program and not get in the way. If all that matters to you is whether it has the widgets you want and has the requisite tools, then there's probably little I can say that will sway you.