Newsletter sign-up
View all newsletters

Enterprise Java Newsletter
Stay up to date on the latest tutorials and Java community news posted on JavaWorld

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

  • Print
  • Feedback
The word portability has, as its root, the verb "to port," which in software terms means to adapt and recompile software to run on a different computing platform. Portability is the ability of a program to be recompiled for another platform. Because creating and maintaining several independent versions of a program is very expensive, portability has long been one of the holy grails of the software industry. Software vendors would like to be able to develop and maintain a single version of their product that can run on many different systems and serve many different market segments.

Previous efforts to enable portability have included a multitude of standards efforts, some interpreters, and a few portable runtime systems. Most have required recompilation; none have achieved mainstream success. In the meantime, economic pressures on software developers and the urgency of delivering a multiple-platform solution in a timely fashion have made the goal more desirable than ever.

Portability and Unix
The Unix programming environment, as codified in the POSIX standards, took a major step toward portability by delivering "source code" portability. Basically, a software product that runs on one POSIX platform can be ported to a new POSIX system by recompiling the source programs -- ideally, with no required source code changes. In reality, source code changes and the consequent burden of multiple versions are often required and unavoidable.

Portability and X Window
Other systems -- such as the X Window System -- address portability issues by providing a layered architecture that isolates system-dependent functionalities. The X architecture successfully abstracts the details of the window and display system. A program using the X Window System can use any X Window display hardware, although that program is still tied to a specific instruction set and operating system architecture.

Portability and Java

Neither the Unix or X Window efforts went far enough to provide universal portability. The Java programming environment, however, makes a significant step toward achieving this elusive goal. From the beginning, Java technology was intended to provide a programming environment that supports the write-once, run-anywhere (WORA) concept. Java technology has largely delivered on this promise by ensuring that Java programs will run across all Java-enabled platforms. Achieving this goal has reduced system dependencies to a very large degree.

When faced with a new computer architecture, a Java program does not need to be ported to it, or recompiled -- one delivery format serves as a universal program representation, usable on all Java-enabled computers. This capability has been achieved by a combination of a well-documented binary representation, the class file format, and a class library that makes the underlying platform functionality available through a universal abstraction layer, the Java Core APIs. We, therefore, prefer to speak of a Java program's runnability rather than its portability. A Java program does not need to be ported to a new computer -- it can simply be run. A Java program can contain constructs, however, that will deprive it of this property of runnability across all platforms. It is possible to unintentionally write a platform-specific Java program, since not all digital systems can be perfectly abstracted. For example, the file-naming convention in operating systems and display resolutions in hardware devices present different behaviors that may impede runnability.

  • Print
  • Feedback

Resources
  • Java Testing Tools from Sun include JavaStar GUI capture-replay, with the ability to write predicates that use the real Java objects; JavaScope, coverage measurement for Java programs; JavaSpec, a tool for creating method-level test programs; JavaLoad, stress testing for Java programs; JavaLoom, a static analyzer for thread behavior; and JavaPureCheck, a checker for portability of Java programs http://www.sun.com/suntest
  • James Gosling, Bill Joy, and Guy Steele, The Java Language Specification, Addison-Wesley 1996 http://java.sun.com/docs/books/jls/
  • Tim Lindholm and Frank Yellin, The Java Virtual Machine Specification, Addison-Wesley, 1996 http://java.sun.com/docs/books/vmspec/
  • Boris Beizer, Software Testing Techniques, 2nd Edition, Van Nostrand Reinhold, 1990 http://www.faqs.org/faqs/software-eng/part3/section-13.html
  • G. Rothermel and M. J. Harrold, "Selecting Regressions Tests for Object-oriented Software," Proceedings of the Conference on Software Maintenance, IEEE Computer Society Press, 1994, pp. 14-25 http://www.computer.org/
  • R. M. Poston, "Automated Testing from Object Models," Communications of the ACM, 1994, 37 (9), pp. 48-58 http://www.acm.org/pubs/
  • D.E. Perry and G.E. Kaiser, "Adequate Testing and Object-oriented Programming," Journal of Object-oriented Programming, 1990, 2 (5), pp. 13-19 http://www.sigs.com/publications/joop/
  • Roger Hayes, 100% Pure Java Cookbook, Sun Microsystems Inc. 1998 http://java.sun.com/100percent/cookbook.html