Java is bad. Java must die. Such were the declarations from pundits earlier this year, in the wake of security holes revealed in Java by high-profile cyber-attacks. The Department of Homeland Security (no less) issued an advisory statement to the effect that users should consider disabling Java in web browsers until the right updates were available – and hammered another nail into the Java coffin by stating that new Java vulnerabilities were likely to surface as well. If Java goes away, so does the need for Java testing. So what was behind all the hoo-hah?
Out of the Sandbox Thinking
The problem with security came from a hacker’s discovery of a way to get Java programs (applets) to access system resources without the system user being warned. In theory, Java applets operate within the perimeter of the Java Virtual Machine sandbox and are limited in the things they can do. Any attempt to move outside of these limits should first result in a warning and request for confirmation being issued on screen to the user (who is free to refuse). Testing of Java applets therefore needs to include datasets with Java testing input designed to test for such security holes.
Java Naysayers and Prophets of Imminent Demise
Estimates of the number of users who really need Java can be as low as 10% or less: the reasoning is that disabling or uninstalling Java is unlikely to affect the online experience for these users. In addition, many users never realize that Java is installed on their machines until they receive a notification that an update is available. Java security problems have affected the Mac OS in particular, leading to an Apple embargo on Java as well as the one from Homeland Security (another example of government agency interaction with industry IT issues).
Oracle and other White Knights to the Rescue
Oracle, the keeper of Java technology, made rapid releases of bug fixes to counter the security problems found. Other industry observers noted that the security problems were more in the client site applets (although serious nonetheless), rather than in the server side web applications. The distinction is important because this use of Java runtime software is built into many business applications and would be difficult to transform overnight into some other technology.
People Still Drink Coffee (and Developers Still Use Java)
Whatever the criticisms, Java is unlikely to go away any time soon. Not only does the installed base mean that ongoing maintenance and Java testing will continue for some time into the future, but recent software projects also use Java: Hadoop and Cassandra are just two examples. Consequently, enterprises continue to hire Java developers, with postings for Java skills growing as well as occupying the top spot for hiring wish lists in IT. Even if Java in time may become a legacy language, just like COBOL, Java testing requirements will persist. Automated Java testing will also continue to provide benefits by allowing companies to cope with a still-growing quantity of Java code, and (in the legacy language scenario) freeing up test engineer time for new technologies that gradually take its place.
If you’d like to know how Testing Anywhere, the automated software testing tool , can help you and your team to higher efficiency and better results, try a free Testing Anywhere trial to see what it can do for you.