The recent deluge of Java vulnerabilities that have been released (some patched and some exploited in the wild) has given rise to a chorus of ditching Java. I recall a similar village riot when Flash was the subject of a string of vulnerabilities. The main arguments centered around disabling Java in the browser. While this was sound advice during the period which the vulnerabilities had not yet been patched, the permanent disabling of Java in the browser seemed a bit over the top.

While I personally think that ditching a product because it has vulnerabilities is ridiculous, I figured it was worthwhile understanding the Java landscape to develop a more informed opinion of the possible fate of client-side Java. I chose to analyse web-based Java from two angles: 1) an analysis of the pervasiveness of Java and 2) the Java business model.

The first half of the analysis focuses on how much client-side Java is in use. Let’s face it, we’ll use stuff that we know isn’t good for us if it has enough of a hold on the market (see smoking). So how much is client-side Java being used? According to W3Techs [], about 0.2% of websites use client-side Java, compared to 20.4% using Flash and 92.5% using JavaScript (no surprises there). Netcraft says there are about 200 million active websites [], so based on these numbers there are about 400,000 websites that are using client-side Java. Some of these 400,000 websites may include gaming and banking websites, but that’s not many sites in terms of the Interwebs. So in terms of usability for most users, it doesn’t look like disabling Java in the browser permanently would be a big deal. There doesnt seem to be any revelations on the horizon either, with JavaFX (competitor to Flash and Silverlight) having resoundingly flopped.

The second half of the analisys focuses on what vested interests exist that fight to keep client-side java alive. Shots have been traded back and forth during the client-side Java debate, namely that Microsoft was behind the smear campaign against Java. I find this a little far fetched, particularly given that Microsoft failed to improve Silverlight take up , and it is still well behind that of Flash. Regardless, if we look at the ways in which Oracle ekes a living out of Java we might gain an insight into what forces are at play. Although Oracle generates some Java-based revenue from training and tools, the majority of its Java revenue comes from the 2 billion odd J2ME licences purchased by mobile device vendors. I couldn’t find any figures for what sort of revenue it generates, but given Oracle and Google are currently duking it out in court over an IP dispute for Android’s hacke JavaME, I imagine its a lot. But given that client-side Java appears to be waning, I don’t understand the obsession with maintaining legacy client-side technologies.

The conclusion that I draw out of this is that Java will eventually die. The burning question is: during the process of Java’s demise how well will Oracle support it? There will be a point at which supporting Java will become unprofitable. At this point we will see the number of vulnerabilities balloon and patches being released late or not at all. We may already be experiencing this.

So in the end I support the disabling of Java, but based on the whether your business uses it. Even if Java is experiencing patch lag due to waning support. However, your users are unlikely to know much about the web technologies they are making use of. Large organisations can undertake a detailed requirements gathering process, but this is beyond the reach of small organisations. In either instance, filtering applets at the Internet content filter sounds like an easily reversible first step. Its important to note that, depending on the configuration, this will only block client-side Java on external websites. Some organisations make use of client-side Java on their internal websites. So even if no complaints are received when applets are filtered, they may still be lurking in the organisation.