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.
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.
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.
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.
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.
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.
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.
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?