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 2 of 7

It is also possible to use the Java programming language to write a program that is intentionally tied to a specific platform. If the nonportability of a program is intentional, there is little need to discover it by testing. Such programs fall outside the scope of this article.

In this article we discuss aspects of Java programs that need to be carefully examined and tested to identify where runnability problems may occur, and how to test for runnability. We'll also discuss how to measure the runnability of a Java program, keeping in mind the question: How well does the program deliver on the WORA promise? First, we'll examine some of the details of runnability, then we'll discuss how runnability testing can be incorporated into the software quality assurance process.

Differences in Java environments

In one vision of a perfect world, no testing would be necessary, and there would be no decision to make about the target environments for a program. All computer platforms' Java Runtime Environments (JREs) would be exactly the same, and a program that worked on one computer would work identically on all other computers. But that vision isn't the one promised by Java technology; it is, in fact, counter to the premise on which Java technology is based.

That premise is that the Java Runtime Environment represents the behavior of all computers with a common abstracted interface. However, the details of the actual computer must still show through the interface in some places -- so Java technology doesn't pretend to offer exactly the same behavior on all computers. Different computing platforms have different behavior, and Java technology makes it possible for Java programs to adjust to these differences.

We'll discuss how these differences may occur, what effect they may have on the behavior of a Java program, and how to ensure that the program fulfills its intended functionality on various platforms. The measurements we suggest will also help to delimit and control any expected differences in behavior.

Platform differences

The specification of the Java Runtime Environment (JRE) -- that which a program may depend on -- is quite complete, but it is not hermetically sealed. Platform differences visible from within Java programs include the size and appearance of GUI elements (as abstracted by the Abstract Windowing Toolkit (AWT)), the syntax of file names, and the details of thread-scheduling behavior. For example, a program that looks great on a 1024x800 24-bit display may not be usable on a 640x480 8-bit display. A program that looks great at one window size may, if certain crucial buttons aren't displayed, be unusable at another. A program that depends on a specific font may not work at all on a machine that doesn't have that font installed. Similarly, the syntax of a file name varies widely among the various Java platforms. The java.io.File class provides a useful level of abstraction that, if used correctly, can insulate your program from these platform specifics. However, if you write