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

Proprietary extensions

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

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.

Expected variations

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.

Speed variations

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.

Display variations

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.