Last call for client-side Java

As browser makers move to block vulnerable plug-ins, Java's future as a client-side platform is uncertain

Java developers hate to hear that their language of choice is becoming the new Cobol, but it already resembles that venerable language in at least one respect: Java is used far more often on the server side than on the client. That trend only seems to be increasing.

Case in point: The Mozilla Foundation announced this week that it's blocking certain versions of the Java plug-in from running in its Firefox browser. However, Firefox isn't alone in squeezing Java out of the browser; the Metro-style version of Internet Explorer 10 won't support plug-ins at all, Java included.

[ Also on InfoWorld: Find out what's in store for Java in Oracle's two-year plan. | Keep up with software development issues and trends with InfoWorld's Developer World newsletter. | Master the latest in Java development with our JavaWorld Enterprise Java newsletter. ]

Plug-ins, including Java and Flash, have been typically used to build rich client-side UIs for Web applications. But with the advent of HTML5 and the modern Web platform, many developers have come to believe that the benefits aren't worth the risks.

Java security under fire

The Java plug-ins blocked by Mozilla share common ground: They all contain a vulnerability that can be used to run arbitrary code on a user's PC. Mozilla has used its blacklist to shut out risky plug-ins before, as when it blocked two Microsoft plug-ins in 2009, but it's never barred so many versions of a plug-in at once.

Mozilla isn't the only one concerned about Java's track record on security. According to Microsoft, Java exploits on Windows machines have been spiking. They now far surpass attacks on other risky technologies, including Adobe PDF and Flash.

Plugging the holes isn't really the problem. For example, Oracle issues regular patches to fix Java security flaws as they're found, and the vulnerabilities cited in the versions on Mozilla's blacklist were patched in February.

The problem is that users don't always get the latest patches, due in part to Java's needlessly cumbersome practices. Though it installs its own updater, the patches don't always download and install automatically. If users get in the habit of dismissing the Java notifications, their JVMs can remain vulnerable months after Oracle releases security fixes.

It doesn't help that Oracle tries to underwrite Java with advertising and other annoyances. One recent Java update for Windows installed McAfee Security Scan Plus on users' PCs unless they opted out. Past versions have bundled browser toolbars. If you want users to take security seriously, the updates themselves shouldn't feel like malware.

A better way to handle it would be to ship Java updates through the normal OS update procedure. However, Microsoft discontinued its JVM for Windows shortly after it settled its lawsuit with Sun Microsystems in 2004.

Apple distributes Java patches for Mac OS X through its regular update channel, but it's no better. It's notoriously slow to ship Oracle's security fixes, and critical Java vulnerabilities often persist on Mac OS X long after they've been patched on Windows and other platforms.

The elusive Java app

According to Oracle, Java is installed on some 850 million PCs worldwide, but there's no telling how many of those systems are up to date with the latest patches or how many of those JVMs are used with any frequency. It's not uncommon for enterprises to have custom desktop applications written in Java, and the Eclipse IDE is popular with developers, but consumer-oriented Java applications are rare. A few file-sharing clients might be the only Java applications a typical user ever sees.

Java applets are hardly as popular as they once were, either. If browser makers are leaning toward disallowing plug-ins, the days of Java as a technology for the Web could soon be over. And if PC users don't need Java for the Web or to run applications, they might choose not to install it at all, particularly given its penchant for security flaws.

That leaves mobile as the primary client-side market for Java, where it's derived most of its success from so-called feature phones. However, the growth is in smartphones, with even low-end models making inroads against traditional feature-phones. On smartphones as well, Java's track record is spotty. Apple has blocked Java from iOS, just as it has blocked Flash. While Android is based on Java, its implementation is so nonstandard that Oracle is suing Google over it.

Java's stronghold: Servers

Oracle says it remains committed to client-side Java. Just this week, it announced it had hired two new evangelists to promote its JavaFX rich multimedia technology. But all that shows is Oracle recognizes the need to encourage more developers to use JavaFX. It hasn't exactly been popular since it debuted.

If Oracle can't engage more client-side developers, Java will increasingly become a platform for the data center, where it's under no threat. Oracle's own business applications run on Java, as do those of countless other companies. Java offers a rich collection of APIs that make it easy to build reliable business applications. Competing vendors, including IBM and Red Hat, contribute to a vibrant ecosystem.

In the data center, it's easy for IT staff to keep up to date with the latest security fixes. There, complex server applications can keep humming along, efficiently and reliably, until long after developers of desktop software have left Java behind -- kinda like Cobol.

This article, "Last call for client-side Java," originally appeared at Follow the latest news in programming at For the latest business technology news, follow on Twitter.

This story, "Last call for client-side Java" was originally published by InfoWorld.