|
|
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 5 of 7
Propriety extensions are, in fact, library code that can be called from a program. For purposes of runnability testing, proprietary extensions aren't different from code written specifically for the program -- except that the developer may have less knowledge of and less control over the extension code. Hence, the extensions may require additional testing efforts. On the other hand, if the extensions have been widely used in a variety of different programs and in different Java environments, the programmer may be able to rely on their runnability. Then, he or she can concentrate the testing effort on the program-specific code.
Drivers, service providers, and handlers are various kinds of software that aren't directly invoked by your program but that are invoked by the Java Core API code in response to a request from your program. This class of software includes JDBC drivers, cryptography providers, and protocol handlers. Drivers are an interesting source of runnability bugs. Because they aren't directly referenced by your program, it's easy to miss them when packaging a program. There is no uniform mechanism for locating and installing them, so packaging becomes an issue. Also, different drivers may intentionally have different behavior, or may have platform dependencies that cause different behavior unintentionally.
The specification of the Java Computing Environment (JCE) leaves certain aspects open, giving the implementor some freedom of choice. A runnable program must expect to encounter these allowed variations and deal gracefully with them. Following is a discussion of some of the variations you can expect.
Java computing environments obviously differ in speed. An important point is that they differ not only in absolute speed but
in the relative speeds of different operations. On one system, socket creation may take 400 times as long as floating-point
multiply; on another system, it will take only 100 times as long. This is just one reason to avoid timing-loops in Java programs.
Other reasons are the fact that a timing-loop will obstruct the other threads in your program, including the system threads,
and the presence of a very convenient sleep primitive, java.lang.Thread.sleep. These speed variations, along with the variance in network delays that can be encountered, make it problematic to set a
default value for constructs like network timeouts. The best solution for a Java program that needs to be runnable across
a wide variety of networks is to take a soft timeout: When a timeout expires, pop up a dialog box informing the user of the situation and asking them if the operations should
be retried. An alternative is to get timeout values from a property file, so the user can change them if need be.
Some Java machines have large screens; some have small. Displays may come at various resolutions. AWT layout managers and resources can be used to make a program adaptable to various display hardware. There is usually a minimum configuration that can be supported, and this minimum configuration should probably be documented.