Featured White Papers

• Measuring Risk to Improve Java Software Quality
• Do You Really Get Classloaders?
• Pragmatic Continuous Delivery with Jenkins, Nexus, and LiveRebel
• Your Next Java Web App: Less XML, No Long Restarts, Fewer Hassles
• Coding with JRebel, Java Forever Changed
• 2012 Developer Productivity Report: Java Tools, Tech, Devs, and Data

Sponsored Links

• Graph databases are 1000x faster than relational.

  Learn More!

• Career opportunities at Harman- Careers That'll Rock Your Socks Off.

  Learn More!

• Developer-friendly Java PDF libraries by Qoppa Software

  Live Demos

• Stop blaming your app! Diagnose Java performance issues.

  Free tool >

• UrbanCode: Go From Continuous Integration to
  Continuous Delivery

  Learn More!

Sponsored Links

Optimize with a SATA RAID Storage Solution
Range of capacities as low as $1250 per TB. Ideal if you currently rely on servers/disks/JBODs

"Runnability" testing of Java programs

A unique aspect of Java technology is that programs can run anywhere without recompilation. Here's how to test your programs so that you can find any runnability problems before your customers do

By Roger Hayes and Manoochehr Ghiassi, JavaWorld.com, 08/01/98

Page 4 of 7

This is, in fact, the situation for all testing. Except in the most trivial cases, we can never prove the absence of bugs by software testing. The point of testing is to increase our confidence that most of the bugs in a program have been caught and that the intended functionality has been demonstrated under a controlled set of states. In this light, runnability testing is like any other testing -- it employs standard testing techniques, only with a different emphasis.

Security policy issues

When running Java programs, an important consideration is the Java security model. One of the advantages of the Java platform is that it gives the user very good safety; a security-restricted Java program runs inside a sandbox and therefore cannot damage the user's computer or violate the user's privacy. Any Java program, especially downloadable code like an applet, must expect to run inside a sandbox and must be prepared to be denied access to various system resources, as controlled by the SecurityManager interface.

This security model is another dimension of runnability for Java programs. Developers must understand the assumptions their program makes about the security policy, and how it will cope if the user has chosen to set a different security policy. This, again, is not a consideration exclusive to Java programs; most operating systems have some access control mechanisms, and so any program may be denied access to protected resources. Java technology differs from operating systems only in that it has a stronger and more detailed security model, so that a program is more often exposed to the denial of access.

Extensions and libraries

Another issue for runnable Java programs is the use of various extensions, or class libraries. There is not a clear distinction in form between an extension (intended as an expansion of the capabilities of the Java platform) and a class library (intended as code to be incorporated into the user's program). Indeed, every class library can be regarded as an extension of the platform capabilities. Extensions may be categorized as standard -- as specified by the Java Software Division of Sun Microsystems through an industry consensus process -- or as proprietary. The standard and proprietary extensions have different runnability implications. In addition, there is an important class of external software that a program may depend on that isn't used directly by the program. We'll describe such software as driver software, because it's most often used indirectly, via a service request of some kind.

Standard extensions

A standard extension is an interface published by Sun that conforms to certain criteria for industry acceptance and platform independence. Standard extensions are published as public documentation, and typically are provided with a reference implementation and a compatibility test. These publication standards give the developer a certain level of confidence that a standard extension, if available, will be consistent from platform to platform. This reduces the load on the runnability test -- a standard extension can be treated as an optional part of the Core APIs, and can (if present) be trusted to the same degree. Of course, it's wise to specify what a program should do if a standard extension it uses isn't available, and to test for that specified behavior. Once it has been determined that the extension is available, however, variations in behavior shouldn't be a major consideration.