Let’s start at the beginning.
Java, East of Krakatoa — Java is the name of the fifth-largest (and most populous) island in Indonesia. I’ve been there a couple of times, most recently when I turned 40. My wife and I hiked up to the rim of Mt. Bromo, an active volcano, at sunrise on my birthday. Come on over some evening and we’ll show you our slides over a nice cup of… java. It so happens that a great deal of high-quality coffee is grown on the island of Java, hence the nickname. (It also so happens that I single-handedly consume 3.5 percent of the world’s coffee; hence another nickname for coffee, “Joe.”) In the early 1990s when a team of engineers at Sun Microsystems was developing a new programming language, they toyed around with several names before settling on Java, allegedly because they, too, were coffee enthusiasts.
So, for our purposes, Java is a programming language. I could tell you that it’s an object-oriented language largely based on C++, but if you’re a programmer you already know that, and if you aren’t, you wouldn’t care. Let’s just say that as programming languages go, Java is a pretty nice one. It’s powerful, popular, and — crucially — designed in such a way that once a Java application is compiled, it can run on many different platforms. That’s right, a given Java application can run on a Mac, a Windows PC, a Linux PC, or a smartphone without any modifications. (In practice, that’s a bit of an oversimplification, but it’s a convenient fiction.)
How does Java pull off this feat of legerdemain? It relies on something called a virtual machine. If you’ve ever run Windows or Linux on your Mac using an application like Parallels Desktop or VMware Fusion, you already have a general idea of what a virtual machine is — it’s an environment, created in software, that functions like a physical computer. Just as a Windows virtual machine lets you run Windows on a Mac (or even within another copy of Windows), the Java Virtual Machine (JVM) lets Java software run on any platform. Each host platform has a different JVM that’s designed to run on its physical hardware — for example, Intel x86 chips have one JVM, while ARM chips have a different one.
Now, there’s a little more to it than that, so please bear with me for two slightly technical paragraphs.
First, when I say the JVM lets “Java software” run on any platform, the software I’m referring to is what’s known as Java bytecode. Java bytecode isn’t Java as such, but rather a sort of intermediate language created when Java code is run through a program called a compiler. Ordinarily, this distinction wouldn’t be important to a non-programmer, except it turns out that other programming languages besides Java can also be compiled into Java bytecode, and then run by the JVM. So, someone could write a program in, say, Python or Ruby, and use a special compiler to build that into something that, as far as the JVM is concerned, is indistinguishable from a program written in Java. In this article, we’re concerned with any software that runs in a JVM, regardless of what language it was written in.
Second, a JVM by itself is usually not enough to enable Java bytecode to run on a computer. You also need a platform-specific version of the Java Class Library, which tells the JVM how to do particular tasks on that platform. For example, maybe a Java program contains an instruction to play the system beep sound. Mac OS X does that one way, while Windows does it another way. So, the Java Class Library takes an instruction that the JVM is trying to send to the host platform and passes it on in the form the host platform expects. The JVM and the Java Class Library are almost always distributed together as a package, and that package is known as the Java Runtime Environment (or JRE), commonly shortened to “Java Runtime.” The Java Runtime is sandboxed (much like iOS and Mac App Store apps), which was supposed to help with security, but secure sandboxes are extremely difficult to develop, and the Java sandbox hasn’t fared well — I’ll return to that issue shortly.
To sum up thus far: Any device with a Java Runtime installed can run Java bytecode, which may have been originally written in Java or some other language.
Once Upon a Platform — In the early days of Mac OS X, Apple not only included a built-in Java Runtime (licensed from its then-owner Sun), it actively promoted Java as a “first-class citizen.” Developers were free to write their applications in Objective-C, Apple’s own programming language that was originally part of NeXTSTEP, or in Java. Either way, users would end up with a valid application that looked and felt (more or less) native. (Java apps have often been criticized as feeling “not quite right” because they often use interface elements that are different from those of native Mac apps, but that’s a relatively minor point.) As a result, lots of Mac apps were — and a few still are — written in Java.
Java isn’t just for stand-alone, double-clickable applications, mind you. A Java applet can also be embedded in a Web page. Assuming your computer has a Java Runtime installed, your browser has a Java plug-in (to support embedded applets), and Java support is enabled, highly complex programs called applets can run right inside your Web browser. Before Flash and Silverlight began to catch on, Java applets were a common way to add interactivity and complex computational capabilities to Web pages.
But over the years, Java has gone from first-class citizen to suspiciously regarded foreigner (and not just on the Mac). The whole story is long and twisted, involving a combination of technical, legal, and political issues. I’ll hit just a few recent highlights.
Java — including the tools to develop and compile it, the runtime environments, and various other pieces — has been open-source since at least 2007, but it’s maintained primarily by Oracle Corporation, which acquired Sun Microsystems in 2010. Although Oracle’s implementation of Java isn’t the only one, it’s as close as you can get to the “official” version. For a long time, the version of the JRE Apple included with Mac OS X was always several months or more behind Oracle’s latest version. And this was a problem when, for example, a security flaw was discovered. Oracle might fix it quickly, but Macs remained vulnerable for some time, until Apple caught up.
Let’s talk about those security flaws for a moment. I’m sorry to say the Java Runtime has had a lot of serious security problems, and more turn up all the time. (To be precise, Apple’s Java updates in 2013 alone address 56 unique vulnerabilities.) Notice that I said Java Runtime — it’s not the Java programming language itself that has issues, but rather the environment used to run Java bytecode. Even then, the real problem isn’t the Java Runtime as such, but rather the fact that if your Web browser has a Java plug-in installed and enabled, and you happen to visit a Web page that contains a malicious Java applet, it can do all sorts of serious damage. Some of the flaws enable Java code that’s supposed to stay safely within your Web browser to jump outside the sandbox, as it were, and cause all sorts of mischief elsewhere on your computer. It’s nasty, nasty stuff. And the bad guys have been working overtime to find and exploit these security holes.
Apple has used multiple tactics to address these problems, and for some time now has been trying hard to push users in the direction of not using Java at all.
Starting with Mac OS X 10.7 Lion, Apple no longer includes a Java Runtime with the operating system, but if you try to run a Java app, your Mac prompts you to download and install Java Runtime – it’s a matter of a few clicks. What you get if you do that is not the latest release. Apple gives you a version of Java 6 (that is, build 1.6.x), whereas the latest from Oracle is Java 7 (that is, build 1.7.x). If you want Oracle’s version, you can download it, and installing it will override Apple’s version. But you probably shouldn’t do that, because Java 7 has had even more security issues than Java 6. For the time being, Apple is actively updating its version of Java 6 with security patches, while Oracle is maintaining Java 7 with comparable fixes. And, unlike in past years, Apple is now delivering many of those patches just as fast as Oracle. In addition, Apple has blocked Safari from using certain particularly vulnerable versions of the Java plug-in. (Meanwhile, Java isn’t available at all on iOS, and you can see why.)
Joe on Java — I want to reiterate two main points to be sure they’re crystal clear. On the one hand, neither the Java programming language nor the Java Runtime will hurt you or your Mac. Merely having the Java Runtime installed does not introduce any security risks. In fact, even running stand-alone Java applications is safe, as long as they come from well-known sources. Or, to put it differently, it’s just as safe to run a stand-alone Java app as it is to run any other app (because, after all, any app could in theory be compromised).
On the other hand, having Java enabled in your browser is, at this point, wildly dangerous. I strongly suggest turning it off. To do this in Safari, choose Safari > Preferences, click Security, and uncheck Allow Java. In Chrome, visit
chrome://plugins and click the Disable link underneath Java. In Firefox, choose Tools > Add-ons, click Plugins, and click the Disable button next to the Java Applet Plug-in.
If you’re using the latest version of Safari, you can enable Java selectively for individual Web sites (leave Java enabled, but then agree to each site’s usage of Java individually if you’re sure it’s safe; for details, read “Safari Updates Add Extra Layer of Java Protection,” 26 April 2013). But the number of Web sites that legitimately use Java these days is small indeed, and I suggest leaving Java off in your browser unless you’re absolutely certain you need it.
Now, in case you’re wondering if you should go ahead and uninstall the Java Runtime altogether, I’ll lay it out for you. If you’re running Lion or later, you’ll have the Java Runtime on your Mac only if you tried to run a Java app (in which case, if you still want to run that app, you still need Java Runtime) or you downloaded it from Oracle yourself (again, presumably because you needed it). If you’re running CrashPlan, which I strongly endorse, you currently need Java. (CrashPlan developer Code 42 Software is working on a non-Java version of CrashPlan for Mac, to be released later this year.) Portions of Adobe Creative Suite, including Photoshop, rely on Java. So do OpenOffice, a few games, and a handful of productivity apps. If you need an app that relies on Java, you must hang onto the Java Runtime. Stick with Apple’s version of Java, and turn it off in all your Web browsers.
If you don’t need Java but still have it installed, you can uninstall it. Rich Mogull has instructions for either uninstalling or disabling it, as the situation warrants, in his Macworld article “How to disable Java on your Mac.”
[Java map by Burmesedays. CC-BY-SA-3.0, via Wikimedia Commons.]