User's Manual

Chapter 1 Introduction 5
The use of building blocks created a need for more lenient checking of exception
throw lists compared to earlier SigTest tool versions. Consequently, SigTest tool 1.5
provides both a source and a binary compatibility mode of operation. This retains
compatibility with earlier signature files while adding support for building blocks
and eliminating the unnecessary error messages.
The SignatureTest command recognizes the -mode option that takes the values
“src” or “bin” as arguments for choosing source mode or binary mode. The choice
of which mode to use depends on the type of signature file being used in the test.
This is described in more detail later in these sections:
■ “Setup Command” on page 14 describes how to generate a signature file
■ “SignatureTest Command” on page 20 describes how to specify the mode
when running a signature test
■ “Merge Command” on page 27 describes how to generate a combined signature
file from set of signature files
The difference between the binary and source compatibility modes is how the tool
handles the throws list for constructors and methods (as described in “Class and
Class Member Attributes Checked” on page 3). Constant checking behavior is also
different in binary and source compatibility modes. Although constant checking can
be applied to binary compatibility, it is a necessary prerequisite for source code
compatibility. “Constant Checking in Differing Run Modes” on page 9 describes
these differences in more detail.
Using Custom Signature Loaders
The signature test has a requirement for the Java™ Platform, Standard Edition (Java
SE platform) runtime environment version 1.4 or later. This requirement might
prevent use of the tool on limited or nonstandard environments such as some Java™
Platform, Micro Edition (Java ME platform) or Java™ Platform, Enterprise Edition
(Java EE platform) configurations.
To overcome this, the tool provides support for custom signature loaders that can be
implemented as plug-ins. These plug-ins gather signatures from a runtime
environment when the SignatureTest command cannot be run directly. For
example, you might create a light-weight remote JavaTest harness agent and run the
signature loader on a remote Connected Device Configuration (CDC) compatible
device. Another example is using a wrapped J2EE platform bean as a signature
loader inside a J2EE platform container where any direct file I/O operations are
prohibited.