I still remember the brouhaha raised over Java on the Macintosh, and pronouncements by many of the Macintosh Technorati that Java sucks. (I believe Gruber’s words were Cross-platform crippity-crap Java apps.)

By all of the various posts I’ve seen, I’d think that Java was a complete wasteland while Cocoa was the rolling green hills of programmer nerdvana.

Okay, that’s fine. I set forth building a new custom application for the retail market, and faced with the various choices for building a cross-platform system I decided to build a simple data core in C++ with the Mac UI in Objective C++ and Cocoa, and the Windows UI in MFC/C++. (The common data core is to assure that data can be easily shared, but is a very small kernel: perhaps right now about 10% of the overall code base. So I’m not trying the YAAF-lite solution of building a UI framework on top of Objective C++ or MFC; rather, I’m building the UI twice, with a common set of data accessor routines at the bottom of the stack.)

Nerdvana? Hardly.

Today’s fun-filled afternoon was spent trying to figure out how to do an easy gradient fill for a custom control so it doesn’t have a flat, 2D appearance. With the sheer beauty of the Macintosh UI environment, you’d think would come convenience routines–but not really: the amount of work to build a gradient filled background was about what I’d expect using the Graphics2D class in Java.

And I’ve come to a couple of conclusions while engaging in this little exercise.

(1) The advantages outlined in Jens Alfke’s essay about making superior interfaces only gets you half-ways through the front door. To make it across the finish line requires a lot of nit-picky detail work that the Macintosh Cocoa libraries only sorta help you with. Sure, there is plenty of support for animation stuff which is really freakin’ cool. But to draw my simple gradient in a way which was portable back to MacOS 10.4 (and my business app needs to be supported by the current version and the previous version of MacOS X) required about 120 lines of code–which, while it took a couple of hours to toss together and test, wasn’t the easy exercise that many Cocoa advocates seem to suggest awaits all who come to the Cocoa big tent.

This isn’t to say that there aren’t advantages to Cocoa over Java Swing or MFC. However, there are many places where Java’s framework has a clear advantage: the JScrollPane class, for example, is a lot more flexible to work with than the NSScrollView class. And don’t even get me started on NSTreeController, though Rentzsch’s comments on enabling NSZombieEnabled was a god-send.

A corollary to this is:

(2) Macintosh applications look great because Macintosh programmers sweat the details, not because the Macintosh environment makes sweating the details any easier than in Java or Windows MFC. It could very well be the Macintosh market: people expect pretty applications, and so a lot of attention goes into making pretty applications on the Macintosh. This attention to detail, however, doesn’t really exist in the Windows market–and don’t even get me started on Enterprise Java applications. (I will agree with Gruber on this: a lot of Java Enterprise Swing applications do look like crap.)

However, this does not mean that the look and feel of Java applications are doomed, any more than it means Cocoa applications are uniformly great–nor does it mean to get the same level of greatness on a Java application you must spend two or three times more effort than on a corresponding Cocoa application. (And it’s not like Cocoa has inherently better support for creating icons like Panic’s beautiful icons, as opposed to the type of 1980’s icons you see in Java: nowadays they’re both PNG files.)

This attention to UI detail, by the way, predates Cocoa, and even predates NeXT, as anyone who ever read the original Apple Macintosh Human Interface Guidelines would attest. In fact, if anything, NeXT programmers and Cocoa programmers prior to the Apple merger weren’t exactly producing stellar examples of UI goodness: I’d say the biggest problem that I saw as an outsider when Apple and NeXT merged was having Apple’s attention to UI detail and usability drilled into the NeXT programmers–much to their shock. Even today I’d say that Apple’s attention to UI detail is only about 90% of what it used to be in the Mac OS System 7 days.

And that attention to UI detail wasn’t because Mac OS System 7 was a fantastic object-oriented development environment. (I should know; I was writing software for System 6 and earlier.) It was because you would sweat details like the fact that on System 6, an OK button was offset 14 pixels–not 15, not 13, not 8–from the lower right of the screen and was 58 pixels wide, not 57, not 59. (Now I will say that System 6 was superior in one aspect to Microsoft Windows–a superiority which existed for quite a few years: Macintosh QuickDraw’s CopyBits() routine was light-years ahead of any bit blitter available on Windows or on X windows: it would anti-alias, crop, stretch, extrapolate, and even fold your laundry and put it away for you, giving the Mac OS System 6 platform a clear advantage over Windows 3.1. But Windows and X windows caught up in that department long ago.)

So anyone from the Macintosh Technorati who suggests that Cocoa is inherently superior–I’m used to religious wars, even from people who should be intelligent enough to know better.

Oh, and for the curious, I’ve attached my GraidentFill class in Objective C using the CGShading routines to handle my custom control shading. It’s really not as flexible as the 10.5-only NSGradient class, but it does the trick.