Java and the Mac Platform – an Ironic History

If you haven’t heard already the latest Macs being sold by Apple no longer are shipping with Java pre installed. This is a good thing and a bad thing. There’s also a lot of irony in this move when you think about the history of Java on the Mac. For the uninitiated Java is a virtual software environment that lets a software developer write their software once and run it anywhere (that has Java installed). The promise was to make the operating system less relevant and focus just on the application. Software developers could write the same code and deploy it on Mac, Windows, HP Servers, and cell phones. The reality was more of write once, debug everywhere since the Java Virtual Machines (JVM) might vary by platform and version. In the beginning the hardware and software manufacturers like Microsoft and Apple built their own JVM and bundled it with their OS. This gave the end user choice of which JVM they wanted to install and increased the complexity of supporting Java. Microsoft quickly realized the folly of this model and abandoned it. Until recently Apple still packaged the JVM with the OS.

Java applications can be packaged on the Mac to look just like any other application. One such application that I use every day is called Oracle SQLDeveloper. I download and run this app without having to think about Java or virtual machines. The only reason that I know that it is a Java app is that it is so ugly. It does not follow the Mac’s human interface guidelines and looks just as bad as it does when it runs on Windows.

It is a good thing that Java will no longer come bundled with the OS. The main reason is security. The JVMs have grown in power and complexity. With complexity comes the risk of a security vulnerability. Today Java can be called within a web browser. The user is given a warning message that they scrutinize with all the forethought of Pavlov’s dog before clicking OK. This leave the end user open to drive-by attacks just by visiting the wrong web site. Left unpatched this could leave your computer open to a remote attack. Apple regularly puts out software security updates specifically to patch the version of Java installed on its computers. These updates come at a considerable expense to Apple and to their customers who must vet these updates whenever they come out. This is a lot of work for a part of the OS that is not typically used by the end user. So you have a lot of risk and work with not much benefit.

When Apple does update the version of Java in the OS they run the risk of breaking some arcane piece of software that has not been updated in years. When that happens Apple has an unhappy customer. This puts Apple in a no-win solution. They did not create the bug or the old software but they get the bad press when it breaks.

In a situation where the user knows what Java is and has chosen to manage it themselves the bundling in the OS posed a different problem. Because it is bundled with the OS, Apple takes a conservative approach to which version they install. For a long time Apple shipped with Java 1.1 active while the world had moved on to Java 2. Java 2 was actually installed on the computer but it just was not enabled as the default version on the machine. This was because the Java 2 version would break some older programs. By taking the conservative approach Apple was able to dodge one complaint in favor of another.

To see what version of Java you have on your computer open up Terminal and type “java -version”.

$ java -version
java version "1.6.0_22"
Java(TM) SE Runtime Environment (build 1.6.0_22-b04-307-10M3261)
Java HotSpot(TM) 64-Bit Server VM (build 17.1-b03-307, mixed mode)

Nearly two years ago I ran into the version issue while taking a Java class. I wanted to use Xcode as my development environment but it kept giving me syntax errors because my machine was using an old version of the JVM. Through some tweaking of configuration files I was able to configure Xcode to use the current version of Java already installed on my machine. I did have to repeat this process whenever my system was updated for a newer version of the OS as Apple would revert the setting back to their delivered settings.

How to Set the Default Java Compiler Version in Xcode

This all became moot when Apple deprecated Java development in Xcode later in 2009. This is ironic because only five years earlier Java was positioned as an enticement to lure developers to the Mac platform. The packaging of Java apps made it very easy for developers to bring their existing software applications to the Mac. This is not the first time that Apple has so radically changed directions on its users. The predecessor of Xcode was a program called Project Builder which was used to build Objective-C applications on Open Step, the predecessor of Mac OS X. Around 1998 the primary use for Project Builder was to make WebObjects applications. Apple adopted Java and deprecated Objective-C. Developers had to rewrite their applications in Java to continue on the platform. Years later Apple would shutdown WebObjects as a product although it lives on today using the Eclipse development environment. As Project Builder became Xcode it supported multiple languages but over time it returned to its Objective-C roots.

It is a bad thing that Java will no longer be bundled on the machine if you are a Java developer because the absence of a JVM will present a barrier to new customers. Given the choice between a native application from the Mac App Store and one that requires me to install and maintain Java, the native app wins. Apple has already stated that apps that rely on Java will not be permitted in the new App Store. They are going to force the native app model.

People who need Java will still be able to get it and install it so long as Oracle decides to continue to support the Mac platform. Apple is extricating them from their dependency on this third party developer and in the end improving the security and user experience for their customers.