Subscribe to CIO Magazine »

Pull the plug on Java before it's too late

Java was created to hurt Microsoft under a foolish strategy to accelerate the commoditisation of hardware and software

Java really never did make sense - not that it wasn't a good idea, more that it didn't make sense for a company such as Sun Microsystems, which largely made money selling expensive servers and workstations, to create it.

Sun had no real business inventing and then owning a largely free client-based platform that mostly ran in browsers. Java was created to hurt Microsoft under an incredibly foolish strategy to accelerate the commoditisation of hardware and software. Since hardware commoditised first, Sun went to that great corporate graveyard in the sky, and Oracle took over.

Oracle is now an enterprise-class, revenue- and profit-focused, back-office vendor and Java is still largely an in-browser, free, client platform. It appears the only reason Oracle is keeping it is in the eventual hope it can get a ton of money out of Google for breaching its license-an effort that seems to have become a money hole rather than a money source.

Write once, read everywhere a 9/11 cyber attacker's dream

One of the best protections against an international catastrophic security breach or systems crash along the lines of the digital 9/11 the Department of Defense has been warning against is that most critical systems don't talk to each other and the related application platforms are very different.

Java falls short of its write-once, run-everywhere goal, but it came darn close to it. That provides a common platform that a hostile entity can use to gain access to client systems such as cellphones to PCs. Java can also be running on the systems used as administrative consoles, suggesting it would be an ideal first target if a hostile entity wanted to do massive damage to a company-or country.

Were Java to stick around, a massive security effort would be needed to assure that such an attack was identified quickly and mitigated near instantly once discovered. The chance for an exploit to move to a global scale is simply too great.

The Java security danger is real

The security exposure is not only real, it is known to attackers. We realised this last week when the second zero-day Java exploit in less than a year emerged. A security warning hit the TV networks, and even the Department Homeland Security in the US issued a warning to immediately disable the code on its systems to avoid losing confidential data.

Oracle appeared to act quickly, but advice emerging suggests that Java is too unsafe to continue to use, partly because Oracle's patch appears to be inadequate.

However, Java is so entrenched that removing it, or even disabling it, is problematic. It is deeply embedded in browsers and used widely by legacy applications that have a legitimate business purpose. It exists in everything from point-of-purchase terminals to administration consoles. Without Java, many businesses simply can't function.

Oracle will likely abandon Java in face of mounting threats

While the benefit of getting money out of Google lawsuit appears to be evaporating, the potential liability and brand damage that Oracle could suffer should a major breach be tied to an inadequately patched Java continues to escalate. If this were a strategic product, Oracle would bite the bullet and assign the required resources to it.

However, Java isn't strategic to Oracle, and you could say the firm operates as a funding source for Larry Ellison's yacht, private island and other hobbies. At the international scale that a Java catastrophe could generate, there is now an increasing and likely chance that Oracle could collapse under a mountain of litigation.

Even if Oracle dodged that bullet, the brand damage to any company tied to an exploit of this magnitude would likely do collateral damage to the firm's sales prospects. That is something neither Oracle's sales team nor Ellison are likely to ignore. I would imagine, in fact, that Oracle's leaders are gaming how to elegantly pull the plug on Java this month. They aren't stupid people.

This suggests an aggressive strategy to remove Java dependence should be on the short list of things to do this year, if not this quarter. Once Oracle spins out the product, likely to a poorly funded open source organisation, Oracle's need to keep it patched and secure will evaporate-and the likelihood of the product becoming a door into your shop will increase exponentially.

Anyone still hooked to Java at that time will be in immediate crisis. Those who have already distanced themselves from the offering will be in far better shape.

However painful it is, and it will be painful to many of you, not acting in a timely manner will prove to be insignificant if your inaction leads to a massive corporate breach or catastrophic failure. It is past the time to say goodbye to Java.

Rob Enderle is president and principal analyst of Enderle Group.

Join the CIO newsletter!

Error: Please check your email address.

Tags cybersecurityGoogleSun MicrosystemsMicrosoftjavalegalLegal | Cybercrimezero-day exploitcybercrimeOracle

More about GoogleIslandMicrosoftOracleSun Microsystems

Join the CIO Australia group on LinkedIn. The group is open to CIOs, IT Directors, COOs, CTOs and senior IT managers.




What about android??



Android uses and maintains its own Java Virtual Machine. If Oracle pulls the plug, Android should be fine, as far as I know. I could be wrong. Perhaps it would mean Android app development would have to move to running on the native hardware, which doesn't sound so bad if the SDK makes the process easy enough...



There is far more to Java than being an 'in-browser, free, client platform'.
Java really shines when used in the backend and middleware of Enterprise systems, and I can't see that stopping any time soon.



What a load of rubbish. Java was around well before Microsoft tried to alter it.



This article seems to have muddled the difference between Java running on the PC versus Java the platform which powers many of the high performance websites, enterprise applications and popular apps in use today.

Java on the desktop is where the security vulnerabilities have been found and have been patched. Java on the server however is as robust as ever and Java is a staple of Enterprise backend platforms and architecture.

Oracle invested in Java because the tools to configure all their products, including their well known database products are also written in Java. Their target market of enterprise customers are also writing their enterprise systems in Java and thus Oracle can build these relationships and grow opportunities where Sun couldn't. It is not these applications of Java that have suffered the security vulnerabilities that the author suggests we should throw Java away for.

The Android platform is also very heavily dependent on Java. Even if Google have forked their own VM, the interim step to building an Android app requires using Oracle's Java version. In addition Google have invested a lot in the tooling used to build an Android application, and you guessed it, these tools are written in Java also.

Such tools cannot be discarded and rewritten in a quarter or even a year. In fact to do so would cause such an engineering burden that they would be rushed, and contain more security vulnerabilities than that of the peer reviewed and now open source contributed work that has gone into the Java platform for the last 15 years.

The article suggests that because administration tools that control servers are run on a client, that the services that the client is controlling are equally vulnerable. The recent vulnerabilities have affected the client, and allowed access to resources on the clients machine only. If an administration tool running on the client was compromised, it would be on the client's machine only where the attacker could access. Not the server where the business critical infrastructure is. This is the opposite of a website frontend, where if hacked, can more likely lead to a compromise of a backend services since a vulnerability in a website may expose direct access to the backend server that the website may be sharing resources with.

Throughout IT's history, vulnerabilities have been discovered in software. Can you imagine if for the scores of vulnerabilities in Microsoft Word over the years, we all stopped using it? Instead responsible vendors have made measures to address the issue and Oracle has not been a slouch in addressing these issues either. Articles like these unfortunately spread unnecessary fear, uncertainty and doubt and could lead decision makers to use alternatives that aren't as mature or secure.

Comments are now closed