The recent Java bug is in the SecurityManager. In other words, the hole threatens mainly applets or Web-delivered Java fat clients. I generally don't enable that stuff because little I use on the Internet can't live without it.
You probably know the SecurityManager as Java's "sandbox" introduced with Sun's marketing of Java Applets. It also has uses on the server. The SecurityManager is essentially Java's equivalent of SELinux or AppArmor, although it predates both. It tells Java which class can execute which "risky" functions (such as accessing the file system). You can implement a more coarse-grained version of much the same on a process level with Unix file permissions, the aforementioned AppArmor/SELinux, or a combination of technologies.
More about Java security
Developer soapbox: Why it's time to adopt applet alternatives and deprecate the Java Plug-in
Want more Java enterprise news? Get the JavaWorld Enterprise Java newsletter delivered to your inbox.
Some Java desktop applications like the Eclipse IDE are rarely Web-delivered and rarely even run in the SecurityManager. In other words, they're unaffected.
The people who will be most affected are Swing users, due to a few widespread applications dependent on client-side Java. Me, the only thing I use is WebEx. I keep a separate browser installed that I fire up only for WebEx.
The bug reduces some options for Java multitenancy (running applications from multiple providers in one JVM), but most multitenanted environments do not depend on a single JVM, using virtualization technologies instead.
Two years until a fix? Not likely
The press has quoted some security expert as saying it will taketwo years to fix the Java SecurityManager. This isn't strictly true; the known exploit is patched. What's really meant here, on closer inspection, is that the SecurityManager couplings are a complicated mess. In other words, they were written by Sun.
While it may take two years to fully deploy a completely redesigned security subsystem for Java, I can't imagine it will take two whole years to fix. Folks have completely implemented the JVM and APIs in less than that time. However, if this is tied to a major release like Java 8, we're talking two years easy to be fully deployed. Moreover, as it stands, this will likely break compatibility for the people most affected (people who still using Swing, for example). Seeing that many of these applications are "dead code," haven't been updated in a while, and were broken by Java 7, the fix probably will come too late to save the long tail of client-side Java.
That said, because most Java applications are server-side trusted code that doesn't use the SecurityManager, it doesn't matter much to most people.
If SecurityManager is broken, should we go back to C?
Java on the whole is still more secure than C. This seems like an absurd statement -- except that C code is vulnerable to buffer underruns and overruns, while Java code is not (due to the way memory is allocated and recovered). Most privilege escalations have been related to these two common bugs.
The advance of Java was giving application developers just enough power to write powerful applications without requiring such dangerous tasks as managing memory. The next generation of high-level languages hopes to remove the developer from managing concurrency as well. These measures make us safer, and while they aren't targeted only at security, they often have wide-ranging positive security implications.
As for the client...
Java has a major client implementation that's enormously successful and doesn't use the same security infrastructure. It's called Android. It is the beginning, the end, and the future of client-side Java. Everyone else will use AJAX/HTML anyhow. Who cares about the Java plug-in or Web-delivered client-side Java? Not me. Time to advance!
In another week or two you'll find out Flash is still one big security hole with animation features. Disable it in advance. YouTube supports HTML5 video in supporting browsers (Chrome/Firefox), so you won't miss your latest "Gangam Style" parodies. Frankly, Flash is a bigger and more widespread problem that will take longer to undeploy as a mainstream technology. Just remember, when it comes to security, browser plugins are bad ummkay.
Keep up on the latest developments in application development at InfoWorld.com. For the latest business technology news, follow InfoWorld.com on Twitter.