|
|
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
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.
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.
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