Original URL: https://www.theregister.com/2001/12/07/java_or_cocoa_mac_developers/

Java or Cocoa? Mac developers choose their brews

Sun's brood tops the poll

By Andrew Orlowski

Posted in Bootnotes, 7th December 2001 16:44 GMT

Letters Re: Apple pulls OS X guidelines after developer protest

We held over a huge postbag generated by last week's Mac developer story. Was Java up to snuff, we asked? Mostly, opinion was positive. Mostly, but not unanimously...

The fact that Apple developers reacted as they did just shows they still don't get it.

Apple went out of its way to make sure that eg. file name extensions are not an issue for users. The advice to use extensions is good, because standards like WebDAV, etc. will not be changed to appease a bunch of Mac developers stuck in 1984.

Your idea to use Java as a compromise is even more backwards: Java is cross-platform, yeah, but at the cost of aiming at the lowest common denominator. That's almost as bad as suggestion as telling people they should solve the cross-platform problem by just using Windows. Apple made huge strides to ensure that Java sortof feels like a native API, but Java, like C++ lacks a whole bunch of truly dynamic features, which according to the inventors of the term Object-Oriented Programming, who are also the inventors of the SmallTalk language, are a prerequisite for a language to be called object-oriented.

In other words, Java, C++, and C# may be called class-based, object-based or whatever, but they do not fill the standard requirements to be called object-oriented.

That aside, the programming guidelines will not be less offensive by going with Java, since e.g. the question as to use file name extensions or meta-data will not be resolved by using Java instead of ObjC.

ObjC is trivial to learn, any programmer can learn it in less than a day. What has a steep learning curve is all the API, but that is equally difficult with Win32, Java, Carbon or whatever. Unless some irrational people propose that Apple should abandon OOP and stick forever with a procedural legacy API, that learning curve will remain.

So anyone claiming that learning ObjC is a problem, is wrong. What is a problem is to learn the OOP API that comes along with it, i.e. Cocoa.

But if Apple uses C++ or ObjC to create an API for its proprietary system doesn't matter, the learning curve will be equally steep.

Actually, thanks to the lack of flexibility in C++, I'm quite sure that a C++ based API would take even more time to learn, since it's exactly the dynamic features lacking in C++ and Java that allow for software design patterns that simplify APIs and that are not available directly in languages that aren't fully dynamic.

Cheers,

Ronald Anton


I understand Apple's position. The code has to make it to Objective-C if the world is to have any chance. Cast a glance at the mess that is Windows and MFC apps and you shouldn't need long to have your coins start falling down the slot.

Rick Downes

But many more of you are positive about Java on X, and the topic drew some distinguished correspondents…

I wrote the new Encyclopaedia Britannica CD and DVD-ROM applications for Mac OS X in Java, using Swing for the UI elements. While I do use JNI to access some native libraries (that we wrote, mind) most of the application is in Java. My experience has been very positive - the Java team at Apple is top notch.

Kirk A Baker


Now that Mac OS X 10.1 fully supports Java development and execution, Java is indeed, as you suggest, a "happy compromise" for application development.

(I believe that you "don't meet too many Java OS X developers" because it is only since version 10.1 that Java is truly viable, and because for several years Macintosh has not been up to date with Java.)

I have found that Java 1.3.1 applications and applets compiled on Windows run without recompilation on Mac OS X. In fact, in one significant way Macintosh is superior to other platforms: applets run without a plug-in, and therefore without modifications
to the standard HTML tags.
[Like OS/2 did in 1996 - pedantic letters ed.]

The applet runner also runs the latest applets.

Most significant to me and, I think, to general development on Mac OS X, is that a compiled Java application, packaged in its standard .jar file with its associated resource files, will execute when double-clicked, just like any other application;
there is no reason for the end user to know that it is Java.

It is significant and important also that the Java Web Start application (and applet) delivery mechanism is built into Mac OS X, automating the download, execution, and updating of applications.

Finally, for most programs, the speed of Java execution is entirely satisfactory, and even indistinguishable from the performance of other languages.

But there are a few problems that Java developers need to overcome when developing applications that run on Mac OS X.

Several of these revolve around the file system; for example, the Mac user sees (non-Java) applications as files, but Java file choosers see them as folders (as they really are) and allow access to their innards. Other problems concern the Macintosh look and feel versus the Java look and feel, and the different proportions and default sizes of standard interface components; interfaces might need to be laid out differently if the Mac look and feel is used.

All in all, however, developers have never had the amazing portability provided by Java. I was a Mac software developer (and teacher) for 12 years, suffered the market-size envy that all who program for a minority platform suffer, and, upon encountering Java in 1995, vowed that I would never again program for any platform other than Java. My estrangement from Macintosh was long and painful, but Mac OS X has brought me back, and we've made up.

Respectfully,

David 'Uncle Dave' Moffat


I work for a small consulting firm specializing in EAI and biotech. It's a strange combination, but both work with large volumes of data, and both have real time requirements. In EAI, the billing department gets cranky when the databases do not match. In biotech, scientists get cranky if they cannot arrange for their experiments because the database is too slow, too ungainly, or just plain badly designed.

Virtually all of our work is done in Java, because it speaks database and network protocols out of the box. There are improvements we would like in the language, but it is the best of the current breed. Our clients use an amazing array of systems, ranging from older Windows platforms to Sun enterprise servers, VMS machines, and Linux boxes.

It is no accident that several of us (me included) recently bought TiBooks as our primary computing platform. The ability to take a full honest-to-god Unix server running MySQL along to the client is neat. Having a decent UI to demo code with is also neat.

That these are the same box, and the one I develop on as well is very, very handy. Again, time saved is money in the bank for a consultant.

For my clients, the time saved by doing my Java development on X translates to projects coming in on time and under budget.

For me, my stress level is lower because I spend less time configuring my system and recovering from problems. I have used various flavors of Windows, Unix, and the MacOS for fifteen years, and various programming languages for almost as long. Java on MacOS is our best performer.

Scott Ellsworth


And here's a clarification…

Clarification

You wrote: "Oh - unless they are written for WebObjects, which Apple supports on Solaris and Windows 2000. Got that?"

From the view of Apple WebObjects 4.0 and 4.5, your statement is correct, that applications developed using WebObjects under OS X or NT and Windows 2000 can be deployed under OS X, Windows NT or 2000, or Solaris. However, things have changed with WebObjects 5.0. Yes, the WebObjects IDE and tools, such as the tremendously powerful Enterprise Object Modeler, which allows one to define and implement classes based on underlying database entities, still uses the original Yellow Box APIs for OS X and Win32. In fact, the binaries for the IDE tools are nothing more than bug fixed versions of the same IDE tools found in WO 4.5. However, Apple has stated that support for these tools will be limited, as all future enhancements and extensions will be targeted for OS X.

Moreover, the major change is that applications developed using WebObjects 5.0 are completely Java 2 Standard Edition (J2SE) based. Apple completely re-implemented the foundation, WebObjects, and Enterprise Objects Frameworks (EOF) classes entirely in Java. Although Apple Enterprise Services will only provide support for WebObjects based applications under Windows 2000, OS X, and Solaris using Sun's JVM, Apple has un-officially acknowledged that WebObjects will work with any J2SE compliant JVM, including Linux. The only reason that Apple doesn't officially support WebObjects on other platforms is due to the limited budget and resources given to their WebObjects development group.

Best Regards,

Bill Wonneberger