As we discuss Apple's new operating system, there's a strong awareness that, no matter how good Mac OS X itself might be, it can't succeed without applications created outside AppleShow full article

Hide full article

As we discuss Apple's new operating system, there's a strong awareness that, no matter how good Mac OS X itself might be, it can't succeed without applications created outside Apple. As a result, Apple has put a great deal of effort into both encouraging and pressuring developers to produce software that takes full advantage of the new operating system and requires Mac OS X to run - which will in turn convince users to switch. Unfortunately, since Mac OS X and Carbon (the technology that enables programs to run under either Mac OS 8.6/9.x or Mac OS X) are still relatively new, developers have found themselves stuck between the rock of Apple's Carbon rhetoric and the hard place of its incompleteness. Mac OS X 10.1.2 is a major improvement in terms of maturity, but can't yet compare to the Classic Mac OS's two decades of refinement - begun even before the Macintosh, with the initial development of Apple's Lisa computer.

<http://www.apple.com/macosx/>
<http://guide.apple.com/macosx/>

Mac OS X combines several earlier products into a new and modern operating system, and each brings its own identity and user community along. To make things more interesting, some of the threads Apple has woven into Mac OS X have historically gone in different directions; contrast the Classic Mac OS, designed for non-technical people, with Unix, which was intended for programmers. The end product is a surprisingly successful blend, but Mac OS X's mixed ancestry shows up in some interesting ways. Because each of the different elements includes its own interfaces, biases, and applications, it's impossible to get a good grasp of Mac OS X without keeping in mind the varied heritage of its programs. In part one of this article, I'll go over the three application breeds familiar to most Mac OS users - Classic, Carbon, and Cocoa - and explain their strengths and weaknesses regarding the Mac OS as a whole. In part two, I'll talk about the advantages of Mac OS X's Java support and look at applications written purely for Unix, the heart of Apple's new operating system.

<http://developer.apple.com/macosx/architecture/>

API in the Sky -- The defining characteristic of a Mac OS X application today is the set of APIs (Application Programming Interfaces) it uses, the group of requests an application can make of the operating system - from "what time is it?" and "draw this paragraph in Palatino 12 in that window" to "open this URL in Help Viewer." To avoid redundant effort, programs use APIs as much as possible. This means, for instance, that most applications don't need to deal with fonts directly, because they can have the OS generate font menus and display text. Because of Mac OS X's long and complex history, programmers can choose among several different API sets, each of which manifests some of its own characteristics in programs using the API.

Mac OS X can run applications based on Apple's Classic APIs, which are also available on Mac OS 9 (and earlier), and were previously called the Mac Toolbox. Mac OS X also offers the Carbon APIs, a subset of the Mac Toolbox, designed to offer compatibility with Mac OS 9 while also making specific incompatible changes that make possible major benefits under Mac OS X. Carbon's changes enable preemptive multitasking, superior virtual memory, and crash protection for applications in Mac OS X - none of these additional features are available to Carbon applications running in Mac OS 9. In addition, Mac OS X includes the NeXT-developed Cocoa APIs - in fact, many of today's Cocoa applications were previously available under NeXTstep, the operating system developed by Steve Jobs's former company, NeXT.

All three of the above API sets are proprietary to Apple, but Mac OS X also supports a couple important public API sets (covered in part two of this article). First, Mac OS X supports the Java APIs, designed by Sun to enable the creation of programs that use the Java programming language and run on multiple operating systems. Then there's support for Unix APIs through Darwin, Apple's open source Unix operating system foundation. Based on BSD Unix, the Unix API layer is what enables Mac OS X to run the powerful Apache Web server. This richness of APIs gives Mac OS X many more applications than one would expect in a new operating system - but keeping track of the various types of programs can be confusing.

<http://java.sun.com/>
<http://www.apple.com/macosx/technologies/ darwin.html>
<http://httpd.apache.org/>

Classic -- The most familiar programs under Mac OS X - for now, at least - are Classic programs. These are mostly written for Mac OS versions 7 through 9 and tend to run the same as they would in Mac OS 9. To accomplish this, a copy of Mac OS 9 runs as an invisible Mac OS X program (called, appropriately, Classic). The Classic layer of Mac OS X is good enough that most programs run exactly the same under Mac OS X as they would under Mac OS 9. The exceptions are mostly programs that control hardware directly, such as CD recorders, since Mac OS X has new and incompatible drivers to manage such devices.

The broad compatibility offered by Classic is critical for the success of Mac OS X, since the many existing Classic programs enable people to use Mac OS X on a daily basis, getting work done with familiar tools instead of waiting years for programs to be rewritten. Microsoft Office 2001 and Eudora 5.1 are two excellent examples of important Classic programs - the Office applications enabled people to use Word, share Office documents, and crunch numbers normally when running Mac OS X until Microsoft released the carbonized version of Office X in mid-November of 2001. In a similar vein, the Classic version of Eudora is still being widely used in Mac OS X while Qualcomm works on the Carbon beta of Eudora (recent releases of which have improved significantly).

<http://www.microsoft.com/mac/office/>
<http://www.microsoft.com/mac/officex/>
<http://www.eudora.com/betas/>

Because the Classic APIs are based on Mac OS 9, Classic programs can't take full advantage of Mac OS X's new capabilities. In addition, since Classic works by running an entire copy of Mac OS 9 inside Mac OS X, there is a great deal of duplication - some of which is managed well, and some of which isn't. For example, you can connect to file servers through the Classic Chooser, or through the Carbon Finder. Either way, file servers are available to both Classic and Carbon programs, but they show up in different places depending on how you are navigating. The Carbon Finder shows them on the desktop, or under the Computer top-level folder; old Open/Save dialogs and Navigation Services show them at the top level, but lack a Computer container; in Terminal and Unix-based programs, they're under the top-level Volumes folder.

To run Classic programs, it's first necessary to "boot" Mac OS 9, which adds significant startup time for the first Classic program launch; Classic can then stay running until logout or restart, but a Classic crash can still bring down all Classic programs (only Carbon and Cocoa programs gain the benefits of the new protected memory model). Additionally, since there are separate clipboards for Classic/Carbon applications and Cocoa applications, there is a brief delay before synchronizing them, so it's possible to copy from a Classic program and then paste the wrong thing in Cocoa program, or vice-versa.

Carbon -- Carbonized programs running under Mac OS X are more interesting, because they automatically take advantage of improvements introduced with Mac OS X with less effort than a complete rewrite in Cocoa. Some of the major changes are implicit and automatic for all Carbon programs - such as improved memory management and live window dragging. (Taking advantage of other changes in Mac OS X requires explicit support that must be added to any application that's ported to Carbon.) In addition, Apple is now putting essentially all of their operating system development effort into Mac OS X, so the benefits of Apple's ongoing development work have shifted from Mac OS 9 (which is now being revised primarily to support Mac OS X better) over to the new platform. Mac OS X is rapidly getting better, and these improvements are focused on Carbon and Cocoa applications.

<http://developer.apple.com/carbon/>

Once developers have carbonized their Classic programs and become familiar with the new environment, we'll see a resumption of the normal process of development and improvement, instead of the current stage where existing applications are moving to Carbon, but not acquiring many new features. Developers are starting to cease work on their Classic programs and shift attention to Carbon and Mac OS X. The rate at which this transition occurs is important to Apple - if it's too slow, people will continue to use Mac OS 9 for "real work" and consider Mac OS X a toy. As key developers gradually cease Mac OS 9 development, as Microsoft has done, pressure to upgrade will grow stronger.

Distinguishing Carbon programs from their Classic counterparts is made easy by the different window interfaces. Classic programs use the old 2D Platinum appearance (rectangular windows, grey borders, zoom boxes in the upper right), while Carbon (and Cocoa) programs use the Aqua interface, with rounded edges, drop shadows, 3D style buttons, and the colored close, minimize, and zoom buttons in the upper left.

The improvements in Mac OS X open up new possibilities for Mac applications. Most Carbon programs are currently just prettier versions of Classic programs, but Apple doesn't draw attention to that. After attaining feature completeness in Carbon, developers start introducing new features unique to Mac OS X. This was the case, for example, with Interarchy 4.1 and BBEdit 6.1 - both programs merely attained Carbon parity with an existing Classic version. Then came Interarchy 5, which offered OpenSSH encryption for FTP transfers thanks to Mac OS X, and BBEdit 6.5, which included better integration with external programming tools, a Unix shell worksheet window, and a tool for controlling BBEdit from the command line. Because Mac OS X is so rich in new APIs, it offers tremendous opportunities for growth.

<http://www.interarchy.com/>
<http://www.barebones.com/products/bbedit.html>
<http://www.openssh.org/>

Looking beyond the immediate need to migrate programs, Apple is attempting to make Carbon a superior platform for developing new applications, as illustrated by changes in the underlying way the system handles events such as mouse clicks, keystrokes, window drags, and so on. The way Classic programs work is that they run in a tight loop, waiting for the user to do something. During that time, they also voluntarily cede processor cycles to other applications. Even though a Classic application may not be doing anything, it's still wasting processor cycles waiting for events.

In contrast, Carbon applications in Mac OS X can take advantage of a different approach to handling events, called Carbon Events (the same approach Cocoa applications use). With Carbon Events, programs register with the operating system the types of events they will react to and how they will respond to these events. When such an event occurs, the system triggers the right application response, but if nothing relevant happens, the program doesn't consume any processing time. The idea is that this will make programming simpler, since the programmer only has to deal with the specific stimuli they're interested in, and also make the system faster since it will only give programs processor cycles when they have something to do.

<http://developer.apple.com/techpubs/macosx/ Essentials/Performance/Carbon/Carbon_and __OS_X_Events.html>

Cocoa -- After Steve Jobs left Apple, he founded NeXT, which built computers that resembled Apple prototypes - cutting-edge hardware, with many of the same technologies as Macs (Motorola processors, PostScript, etc.). To match this advanced hardware, NeXT developed the NeXTstep software, which was essentially three things, a Unix-based operating system, a windowing system based on Adobe's Display PostScript, and a programming API that enabled the fast development of graphical applications. That API has evolved over the years, becoming OpenStep when NeXT gave up on the hardware business, and then Cocoa when Apple acquired NeXT.

So Cocoa was mature well before it was integrated into Mac OS X, while Carbon was designed and written at Apple starting in the early phases of Mac OS X development. For this reason, Cocoa applications from NeXT developers like The Omni Group and Stone Design had a considerable head start over their Carbon counterparts. As Apple has fleshed out the Carbon environment in Mac OS X 10.0 and 10.1, Carbon and its applications have reached a kind of parity with Cocoa, but each has strengths and weaknesses. Cocoa applications require significantly less work on the programmer's part because of everything Cocoa provides, but writing a Carbon application is a more familiar process for a Macintosh developer. Plus, there are some things Macintosh programmers expect to be able to do that are possible only in Carbon. As Apple continues to work on both, the differences between programs written in either environment will decrease.

<http://www.omnigroup.com/>
<http://www.stone.com/>

It's increasingly difficult to tell the difference between Carbon and Cocoa applications, both of which use the same Aqua appearance, but here are some clues. If it's relatively small, uses drawers (like Mail), has a Font panel for selecting fonts, it's almost certainly a Cocoa application. Another minor distinction that exists currently is the difference between the way Carbon and Cocoa applications let the user navigate Open and Save dialogs (for more on the discrepancies see "Apple's Dirty Little Secret" in TidBITS-601). Apple is wisely trying to iron out the remaining discrepancies in application behavior. In the long run, it shouldn't matter to an end user if an application has an object-oriented NeXT heritage or the Classic Mac OS in its ancestry, although Cocoa applications will always be significantly smaller than Carbon applications, given that so much of the necessary code for a Cocoa application is built into Mac OS X.

<http://db.tidbits.com/article/06594>

Not Your Father's Mac -- As of this writing, Classic is still essential to Mac OS X, since there are many Classic applications without carbonized versions or Cocoa equivalents available. As developers release Carbon and Cocoa programs, Classic will become a vestige of Mac OS history. Already, major software releases for the Mac OS - with the Classic-only QuarkXPress 5.0 being a notable exception - are generally Carbon apps, due to large existing code bases and lack of familiarity with Cocoa. But NeXTstep/Cocoa developers have another opportunity to demonstrate the advantages of their favorite programming environment, and they're hoping to woo existing Mac developers over to Cocoa, which provides all the advantages of Mac OS X for far less effort than writing a new Carbon application.

Mac OS X goes beyond Classic, Carbon, Cocoa, with support for native Unix and Java programs as well. Macintosh development in those environments is just getting started, but as developers previously unfamiliar with the Mac discover what's possible in Mac OS X, Apple's best-of-both-worlds operating system is garnering increasing attention. Part two of this article will take a look at these developments.

[Chris Pepper is a Unix System Administrator in New York City. He's amused and somewhat surprised that Mac OS X has turned out to be such a great management workstation for the Unix systems he works with. Chris is involved in various documentation efforts, including those for Interarchy and the Apache Group.]

<http://www.reppep.com/~pepper/>

Hide full article

READERS LIKE YOU! Support TidBITS with a contribution today!
<http://www.tidbits.com/about/support/contributors.html>
Special thanks this week to John & Nichola Collins, Chris Williams,
John K. Lilley, and Honeymoons By Sunset for their generous support!

In the previous installment of this article we looked at three of the five breeds of programs that run in Mac OS X: Classic, Carbon, and Cocoa. Those three are most notable because they're used for the majority of current Mac OS X programsShow full article

Hide full article

In the previous installment of this article we looked at three of the five breeds of programs that run in Mac OS X: Classic, Carbon, and Cocoa. Those three are most notable because they're used for the majority of current Mac OS X programs. Because all three of these APIs (application programming interfaces) are proprietary to Apple, they're available only in the Mac OS, and Apple is actively working to make them a productive and pleasant environment for Macintosh users and developers. However, Mac OS X also supports the public Unix and Java APIs that provide access to a plethora of cross-platform programs, including many types that aren't available in Classic, Carbon, or Cocoa. This week we're going to concentrate on the wide variety of Unix applications that you can run in Mac OS X; we'll save Java for the next installment.

<http://db.tidbits.com/article/06694>

The core of Mac OS X is Darwin, a full-blown Unix operating system. When you start Mac OS X, Darwin boots up, finds and mounts hard disks, starts virtual memory, and begins running various programs. Some of those programs are Carbon and Cocoa applications, such as the login window and the Finder, but others are standard Unix programs, like the Apache Web server.

Types of Unix Programs -- Unix programs come in many different types, and full-blown interactive applications are greatly outnumbered by tiny command-line utilities and non-interactive server programs. In fact, almost every command you type at the Unix command line is a small program, but one you run from the command line rather than by double-clicking. To access Mac OS X's Unix command-line prompt, launch the Terminal application from the Utilities folder in your Applications folder. Type "ls" (without the quotes) to run the program that lists files in the current directory, which is essentially what the Finder does every time you open a new window. Other core commands include more, which displays text files, and man, which displays online help called "manual pages." To learn about each of these commands, try typing "man ls", "man more", and "man man" (once you've started man, press the space bar to scroll, and type q to exit). Hundreds of these small command-line utilities are included with every version of Unix; to see most of them, type "ls /usr/bin". Don't let this overwhelm you - although it's possible to learn Unix purely from the online help, there are, of course, hundreds of books on Unix available (some were recommended in last year's TidBITS gift issue).

<http://db.tidbits.com/article/06657>

Most of these programs are much simpler and smaller than Mac applications - copy, delete, and list files are three different Unix commands (cp, rm, and ls, respectively). In comparison, the Finder includes these capabilities and a great many more in a single application. Some programs in /usr/bin, however, are full-blown interactive (but text-based, rather than graphical) applications, with their own user interfaces, such as the vi and emacs text editors.

In addition to command-line tools, Unix systems sport a great many server programs, the most well-known probably being the Apache Web server. Apache runs invisibly in the background, responding to requests from Web browsers and recording its activity in log files. This approach is an inversion of a typical Mac application, where the interface is the centerpiece, and the rest of the program exists to satisfy requests made through the interface. There are a few such faceless programs on Mac OS 9, but they're common (and totally essential) on Unix systems.

Most full-blown Unix applications use the X11 Window System (often called X Windows) to provide graphical interfaces. X11 itself may feel more primitive than the Quartz and QuickDraw imaging systems which manage text and graphic display for Carbon, Cocoa, and Classic applications, but X11 is available for a wide variety of systems, facilitating cross-platform development. Because there are so many alternative X11 window managers, it offers tremendous flexibility, far beyond Apple's customization options. In addition, X11 was designed for network environments; X11 programs can display their windows on remote X11 systems across the Internet (even running different operating systems), so X11 programs implicitly include many of the capabilities of programs like Timbuktu. X11 isn't included with Mac OS X, but free and commercial versions are available.

<http://www.netopia.com/software/products/tb2/>
<http://sourceforge.net/projects/xonx/>
<http://www.tenon.com/products/xtools/>

Getting & Installing Unix Programs -- One of the best things about Unix is the vast number of freely available programs, but with this richness comes complexity. Because programs are normally compiled for a specific processor type and operating system (such as Apple's System 7 on a Motorola 680x0, or Linux 2.2 on an Intel Pentium-series processor), Unix programs are mostly distributed as source code kits, intended to be compiled on a variety of operating system/processor combinations. Developers can't test against every system configuration, which makes Unix software far less plug-and-play than Macintosh and Windows software. Worse, Unix programs often require adjustments to their source code to work on a given system; this process of adjustment is called porting. Since most users don't want to port programs before using them (or more likely, aren't capable of it), Unix developers go to considerable trouble to make their software work on a wide variety of systems, but there are always gaps, especially with new operating systems like Mac OS X.

The Unix world addressed this problem with package management systems that simplify the process of porting and installing software. Some, like Red Hat's RPM, install pre-compiled packages, but this approach suffers from size bloat and version dependency confusion. Others, like the Debian GNU/Linux dpkg utility, perform source code porting using automated recipes for compiling software - start with a source package, unpack it, make these changes, compile it with those commands, and install it with another command, and so on. Automated source code porting eliminates the size problems in the pre-compiled binary package approach, but it does require the user to have development tools available, something that's almost certain in Unix generally, but less so in Mac OS X since many people upgraded to Mac OS X 10.1 without getting the Developer Tools CD-ROM. You can download all the Mac OS X developer tools for free, but at over 200 MB, downloading isn't feasible for all users. In reality, most package management systems combine both approaches, in an attempt to provide the best of both worlds.

Several package managers are available for Mac OS X, but Fink - an adaptation of Debian GNU/Linux's dpkg - is currently the best of the lot. It includes straightforward instructions and can install a great many Unix programs without requiring the user to understand the details of compiling and installing Unix software. Fink also normally installs software in its own directory, making it easy to uninstall cleanly, something that's not otherwise guaranteed. Fink is available in both source-only and binary-and-source versions; both can compile a broad range of Unix programs, and the binary distribution includes pre-compiled versions of the most popular software. The neat thing about Fink is that only one person has to figure out how to port a particular Unix program to Mac OS X and submit their procedure, after which anyone else can have Fink follow that recipe and install the same software automatically.

<http://fink.sourceforge.net/>

For Mac users who prefer to avoid dealing with Unix and its applications directly, programmers are creating graphical applications to manage specific Unix facilities. There's Brick House, which provides an Aqua interface to the ipfw firewall built into Mac OS X, or MemoryStick from TidBITS's own Matt Neuburg, which graphically displays your RAM usage using the Unix vm_stat memory utility. There are also more general tools to bring Unix power into Mac OS X's Aqua environment, including ShellShell and DropScript. ShellShell is an extensible tool for generating Unix command lines from a graphical interface, executing them on behalf of the user, and showing any results to the user. It uses its own configuration language, and the author, Robert Woodhead, invites others to submit their own modules for use with ShellShell. Wilfredo Sanchez's DropScript takes a different tack - the user first drops a script containing Unix shell commands onto DropScript to create a new Cocoa application from the script. Then, any files dropped onto that DropScript-created application are processed by the original shell script as if the user had typed the appropriate commands. This makes DropScript an easy way to provide pre-built command line programs to compress, back up, or otherwise manage files from the Finder.

<http://personalpages.tds.net/~brian_hill/ brickhouse.html>
<http://www.tidbits.com/matt/#cocoathings>
<http://www.madoverlord.com/Projects/ SHELLSHELL.t>
<http://www.advogato.org/proj/DropScript/>

Finally, there are a variety of commercial Unix programs. They're often much more expensive than their Mac and Windows counterparts, and sometimes more powerful as well. For these high-end developers, Mac OS X provides a familiar Unix-based environment with OpenGL graphics support (OpenGL is a cross-platform API for accelerated 3D graphics) that facilitates porting products like Alias Wavefront's Maya. Maya is a heavy-duty animation program used for everything up to full-length feature films. Maya would never have made it to Mac OS 9, but it's available on the Mac now, thanks to Mac OS X's Unix core.

<http://www.aliaswavefront.com/en/Tmpl/Maya/html /index.jhtml?page=/en/Community/osx_main _m/osx_main_m.shtml&style=normal>

Environmentally Friendly Mac OS X -- The Mac OS has traditionally stood alone, but Mac OS X's Unix foundation throws open the doors to new applications and uses. Some of those are coming from traditional Unix applications - generally command-line tools and servers - ported to Mac OS X, but that's not all. Brick House and other programs that provide graphical interfaces to Unix tools offer a great deal of power to Mac users without resorting to the often arcane command line. Developers are also starting to take advantage of Unix's power for Mac programs - as with Interarchy, which has leveraged the ssh command built into Mac OS X, and BBEdit, which can now run shell scripts directly. Finally, high end Unix programs like Maya are starting to appear on the Mac. Still, Unix in Mac OS X is something of a wild card - Unix provides vast power and flexibility for text manipulation, networking, programming, collaboration, and security, but how this power will be directly exploited in Mac programs, and by Mac programmers, remains to be seen.

[Chris Pepper is a Unix system administrator in New York City. He's amused and somewhat surprised that Mac OS X has turned out to be such a great management workstation for the Unix systems he works with. Chris is involved in various documentation efforts, including those for Interarchy and the Apache Group.]

<http://www.reppep.com/~pepper/>

Hide full article

Get more productive with software from Smile: PDFpen for
editing PDFs; TextExpander for saving time and keystrokes while you
type; DiscLabel for designing CD/DVD labels and inserts. Free demos,
fast and friendly customer support. <http://www.smilesoftware.com/>

In the first two installments of this article, we looked first at Apple's proprietary programming environments for Mac OS X - Classic, Carbon, and Cocoa - and then at its cross-platform Unix layerShow full article

Hide full article

In the first two installments of this article, we looked first at Apple's proprietary programming environments for Mac OS X - Classic, Carbon, and Cocoa - and then at its cross-platform Unix layer. In this third and final segment, we'll examine Java.

<http://db.tidbits.com/series/1214>

Cuppa Joe -- Sun Microsystems developed Java - which is both a programming language and an operating environment - in an attempt to solve some of the basic problems of computer programming. Their most important goal was to alleviate the challenges of writing code for different platforms. To reduce the need for porting software between these environments, Sun designed an abstract operating environment - essentially a virtual operating system - called the Java Virtual Machine (JVM) in which Java applications would run. By making the way programs communicate with the JVM identical, and hiding platform-specific differences inside the JVM, Sun hoped Java programs would run - without porting - on any platform with a JVM, eliminating the need for multiple versions.

Unfortunately, it didn't turn out to be that simple. Variations between JVMs on different platforms and the desire to provide native-looking interfaces mean that a truly cross-platform Java application is still a difficult task that requires some porting. That said, using Java as a target platform can save time for cross-platform development, and as a modern programming language, Java includes a raft of improvements over the C and C++ languages Sun intended it to replace.

<http://java.sun.com/docs/books/tutorial/ getStarted/intro/definition.html>

Applets, Servlets, and Applications -- Java initially proved popular for small programs, called applets, that could run inside Web browsers, because the interface to such programs was minimal and did not need to be native to each platform. We've all run into a Java applet at one time or another, often with mediocre results or even a browser crash. That's evidence of how the quality of the JVM, as well as differences between virtual machines, play an important role; but there are many Java applets that work fine, such as the Secret Lives of Numbers visualization mentioned in Adam's "A Couple of Cool Concepts" article in TidBITS-617. It doesn't look like a Macintosh program, short of a few of the controls, which makes it harder to use than would be ideal for Mac users, but it does provide a complex interactive experience no matter what operating system or Web browser is used.

<http://db.tidbits.com/article/06720>

Later, Java became heavily used for writing servlets, small back-end Web applications that add customization and intelligence to Web sites without the need for proprietary interfaces. Businesses that need to develop custom Web services but want to avoid being tied to a specific Web server find Java attractive. For example, a Java servlet initially written for the Tomcat Java servlet environment can work with the built-in Tomcat Web server, or in concert with the Apache Web server, or inside any of a variety of commercial servlet environments on various platforms (including Mac OS X). Recognizing this, and in an effort to boost the credibility of Mac OS X as a server platform, Apple now provides instructions for installing Tomcat under Mac OS X and includes it in Mac OS X Server.

<http://jakarta.apache.org/tomcat/>
<http://developer.apple.com/internet/macosx/ tomcat1.html>
<http://www.eweek.com/article/ 0,3658,s%253D708%2526a%253D20204,00.asp>
<http://www.javaworld.com/javaworld/jw-01-2002/ jw-0118-macworld.html>

The popularity of Java for applets and servlets doesn't mean that it can't be used for full-fledged applications. Java programs are frequently distributed as single files, with .jar or .zip extensions, although those that are tweaked to improve the user experience in Mac OS X go further yet. For example, LimeWire is a client written in Java for the Gnutella music-sharing network. LimeWire uses a platform-specific installer and application shell that provides a nicer user experience than double-clicking a .jar file with a generic icon. When you get it running, LimeWire looks pretty much like a Mac OS X program, with an Aqua appearance. The lack of a real menu bar and the presence of underlines under menu item shortcut letters give its Java heritage away, but LimeWire is still easy to use. For a more-familiar application type that doesn't fit into Java's traditional network utility category, check out jEdit, a Java-based programmer's text editor. It provides a real menu bar, though it still underlines the keyboard shortcuts in menu items, doesn't use the proper font for the menus, and avoids Mac OS X's standard Open and Save dialogs. A different approach to the problem of cross-platform interface details is to ignore it, as in the simulation creator Stagecast, whose windows and menus are all drawn inside the program's single master window, and whose interface widgets are proprietary and unfamiliar.

<http://www.limewire.com/>
<http://www.jedit.org/>
<http://www.stagecast.com/>
<http://db.tidbits.com/article/05437>

One question that occasionally arises is whether people can run any Java application in Mac OS X, even if there isn't a download specifically for Mac OS X. The answer is that you can always try - download it, look for a file with a .jar or .zip extension, and double-click it. The likelihood of the program working is higher than in Mac OS 9, so it's worth breaking out of the standard assumption that Macs don't do Java.

Going Mocha -- As I noted at the beginning, Java is both a programming language and an operating environment. Although I've been talking about Java applications that exist entirely within the Java Virtual Machine, it's also possible for programmers to use just the Java language to create full-fledged Cocoa applications for Mac OS X. In this scenario, deliciously known as Cocoa Java, the programmer uses stock Cocoa interface widgets and communicates with the Cocoa application by talking to the Cocoa programming interface, but uses Java for all or part of the code, because she either prefers it to Objective-C, or (more likely) knows Java better because it's more widely used. The Java code runs in the Java Virtual Machine, as usual, but gets its interface from the built-in Cocoa framework, crossing the gulf between the two worlds via a translation mechanism dubbed the Java Bridge. The result is an application that looks like any other Cocoa application, though the overhead of the JVM means it launches more slowly and uses more memory than a normal Cocoa application. For an example, take a look at Tiran Behrouz's Calculator+; you'll find that there's nothing about the interface to reveal that the programmer used Java instead of Objective-C.

<http://tiran.netfirms.com/>

Cream and Sugar -- Because Java makes the underlying platform less important, it's particularly attractive to platform vendors looking to entice developers into writing for operating systems other than Windows. This also means that Java poses a threat to the domination of Microsoft Windows, because Java programs - unlike Win32 and Visual Basic programs - are portable to other systems. As a result (and this is an intentionally massive oversimplification of a complicated situation), Microsoft has withdrawn its support for Java, and now encourages developers to use a derivative language named C# (pronounced "C sharp"). C# is nominally an open language, but it's designed around Microsoft's Windows operating system and .NET platform.

<http://www.javaworld.com/javaworld/jw-11-2000/ jw-1122-csharp1.html>

Apple supported Java poorly in previous versions of the Mac OS with the Macintosh Runtime for Java (MRJ) but has greatly improved the Java Virtual Machine in Mac OS X to provide much more complete and current Java support. Despite the solid Java foundation in Mac OS X, Apple's initial focus has been on supporting Classic and encouraging developers to use Carbon and Cocoa. More recently, Apple has started paying a bit more attention to Mac OS X's underlying Unix layer, and the new attention being paid to the Tomcat Java servlet environment in Mac OS X would seem to indicate that Java may be rising on Apple's list of priorities. In any case, more Java developers are discovering Mac OS X and responding well to Apple's Java support.

An Embarrassment of Riches -- It's ironic: Mac OS X includes the Classic environment for running existing Mac OS 9 applications, Carbon for developers who are porting large code bases over to Mac OS X, and Cocoa for programmers starting from scratch. Then there are Mac OS X's full Unix underpinnings and robust Java Virtual Machine, which together bring a veritable host of Unix and Java applications into the fold. With Mac OS X, the Macintosh has jumped from being known as a closed and isolated architecture to supporting far more programming environments than any other operating system. Who'd have thought?

Hide full article

SYNC YOUR PHONE with The Missing Sync: Sync your calendar,
address book, music, photos and much more between your phone
and Mac. Supports ANDROID, BLACKBERRY, PALM PRE and many
other phones. <http://www.markspace.com/bits>