sun.com docs.sun.com My Sun Worldwide Sites

This document is licensed under a Creative Commons Attribution-Noncommercial-No Derivative Works 3.0 Unported License
  Previous Contents Index Next
Chapter 5

Test-Specific Information

This chapter provides special setup instructions, configuration information, and special execution instructions required to run the following JCK tests:

The configuration is generated from each interview by the Configuration Editor. See Chapter 4 for additional information about creating configurations for test runs.

Note - The configuration tab value names and descriptions provided in the sections of this chapter are used with the JavaTest harness Configuration tab and the Test Environment dialog box during troubleshooting.

You can also set specific configuration values in the command line for a test run. If you choose to do so, see the JavaTest Harness User's Guide: Command-Line Interface, or the JavaTest harness online help for a detailed description of setting configuration values in the command line. You must use one of the following sources to identify the question-tag name to use in the command line:

  • The Question Log file (questionLognnnn.html) generated by the Configuration Editor in workdirectory/jtData

  • The config.html report generated from the JavaTest harness GUI

  • The Question Tags displayed in the Configuration Editor

See the JavaTest Harness User's Guide: Graphical User Interface or the JavaTest harness online help for a detailed description of displaying the Question Tags in the Configuration Editor and generating reports containing the config.html file.

Note - The questionLognnnn.html and config.html files can be viewed in any web browser.

Configuration values that you set in the command line are not saved in the configuration file. Use the Configuration Editor or the command line Edit JTI utility to modify the configuration file. See the JavaTest Harness User's Guide: Graphical User Interface, the JavaTest Harness User's Guide: Command-Line Interface, or the JavaTest harness online help for a detailed description of using the Configuration Editor or the Edit JTI utility to modify a configuration.

5.1 How This Chapter Is Organized

This chapter is organized alphabetically according to the major test categories of each interview. Each test category has four sections (see Table 5-1) that describe information specific to the different types of JCK tests.

Table 5-1 Test Information Sections and Descriptions

Information Section

Description

Setup

Special steps (if any) required to setup specific tests prior to running them.

Configuration

Configuration information (if any) required to run specific tests.

Execution

Special instructions (if any) required to execute specific tests.

Configuration Tab Name-Value Pairs

Configuration tab name-value pairs are provided in this chapter for you to use with the JavaTest harness Configuration tab or Test Environment dialog box when troubleshooting problems running a test.

When viewing Configuration tab name-value pairs in this chapter, note that questions in the interview, properties in the configuration file, and the actual parameters of the test could be different. For example, the JavaTest harness uses the TestScript plugin to calculate some test parameters from configuration file values.

If you set a configuration value in the command line, you must use the Question Log, the config.html report, or the Question Tags in the Configuration Editor to identify the question-tag name used in the command line for that configuration.

See Appendix A for a detailed list of entry names and values used in the test description table.

The majority of test-specific information pertains only to the runtime tests. Java platform Remote Method Invocation (Java RMI) and floating-point tests are the only compiler tests that require any special action.

5.2 Annotation Processing Tests

Annotation processing testing is a three-step process in which the input .java source file is processed using the Java compiler and annotation processing options, the annotation processor writes the test status into a file in the test work directory, and the harness checks the test execution status file created by the processor. Table 5-2 provides the location of the annotation processing tests and identifies the areas that are tested.

Table 5-2 Annotation Processing Test Information

Test Information

Description or Value

APIs tested

javax.annotation.processing

javax.lang.model and subpackages

Test URL

api/javax_annotation/processing

api/javax_lang/model

5.2.1 Setup

When rerunning the annotation processing tests, verify that the work area does not contain class files created during a previous test run.

5.2.2 Configuration

Each annotation processing test consists of an annotation processor and an input .java source file. The annotation processor contains the test code that checks the specification assertion. The input .java source file, when correctly processed by the compiler, produces structured output expected by the test.

Note - The configuration steps for annotation processing tests described in this chapter are only needed for the command line compiler. The JSR 199 compiler uses the standard API and does not require the additional configuration.

To create a configuration for running the annotation processing tests, you must specify the following templates in the interview:

  • Processor template — Passes the processor class name to a compiler. Each test has its own processor class. The class name is stored in the apClass test description field.

  • Processor specific options template — Passes the processor options. The following options are two JCK standard options that are defined by harness and passed to test:

    • jckTestWorkDir contains the test work directory. The value passed in the jckTestWorkDir option is used by processor (test) to write the file that contains the test execution status. After the test is complete, the harness reads the status file from that directory and detects whether the test has passed or failed results. The tests write their execution status into files located in the specified directory. The JavaTest harness uses these files to detect whether the test has passed or failed results.

    • jckApArgs contains the value specified in the test description apArgs field. The apArgs field is an additional way to pass the options to a test by analogy with executeArgs. Not every test has apArgs field.

      Note - Each test has its own test work directory and processor arguments.

  • Source output directory — Stores the files generated by the processor.

The harness uses the templates and values from the configuration to generate the compiler command for annotation processing tests. The compiler command generated by the harness passes the annotation processor, source output directory, and processor-specific option to the Java compiler.

Table 5-3 provides the names and descriptions of the templates required to create a configuration for running the annotation processing tests.

Table 5-3 Annotation Processing Test Configuration Templates

Template Name

Template Description

Annotation Processor Option

A template for the processor option. In the option template, the pound sign (#) indicates where the processor class name is specified.

Example:

-processor #

Source Output Directory

A template for the source output directory option. In the option template, the pound sign (#) indicates where the source output directory name is specified.

Example:

-s #

Processor Specific Options

A template for passing processor-specific options to the annotation processing tool. It is used to pass key-value pairs to the Annotation Processing test.

Example:

-A#key=#value

Following is an example of the annotation processing command line generated by the harness for the standard JDK software on the Solaris operating system:

... -processor $apClass -AjckTestWorkDir=$testWorkDir \ -AjckApArgs=$apArgs -s $testWorkDir ... $testSource

In the example, the following options and values are used:

  • $apClass — Annotation processor class

  • jckTestWorkDir — Special option name for passing the test work directory

  • $testWorkDir — Work directory for a test

  • jckApArgs — Special option name for passing the additional arguments to a test

  • $testSource — .java source file to be processed by the processor

5.2.3 Execution

No special requirements.

5.2.4 Configuration Tab Name-Values Pairs

The user must enter templates as described in Table 5-3. The harness uses the templates and values from the configuration to generate the name-value pairs displayed in the GUI.

5.3 AWT and Swing Tests

Table 5-4 provides the location of the AWT and Swing tests and identifies the areas that are tested.

Table 5-4 AWT and Swing Test Information

Test Information

Description or Value

APIs tested

java.awt and subpackages

javax.swing and subpackages

Test URLs

api/java_awt

api/javax_swing

5.3.1 Setup

The AWT and Swing tests contain batch and interactive tests. Because interactive tests require keyboard and mouse input, you might decide to run them separately and not batched with the rest of the test suite. All interactive tests contain the interactive keyword. In addition to the interactive keyword, some AWT interactive tests contain the robot keyword. This enables you to specify keywords used to filter or include these tests in a test run. In addition, if your platform supports it, many of the tests that might require human interaction can also be run without interaction by using the java.awt.Robot class. Tests that use the robot can be selected or deselected by specifying the robot keyword in the configuration. For more information about using keywords in the configuration, see Chapter 4.

Running the interactive tests separately reduces the time required to find the tests that use the interactive or robot keywords. To run the interactive tests separately, specify in the configuration that only AWT and Swing tests are run. See Chapter 4 for detailed information.

The AWT interactive tests are located at api/java_awt/interactive/index.html.

The Swing interactive tests are located at api/javax_swing/interactive/index.html. For more details, see 5.10 Interactive Tests.

5.3.2 Configuration

When testing on X11 window systems, the DISPLAY and HOME variables in Table 5-5 must be set in the test environment.

5.3.3 Execution

Some AWT and Swing tests require user interaction. Interactive tests have been developed using two kinds of user interfaces: a Yes-No interface and a Done interface. Tests that use the Yes-No interface request the user to perform a visual verification and keyboard-mouse actions, and to click Yes or No to declare whether the test passed or failed. If the user clicks No in the case of a failed test, the user is prompted to enter text that describes the failure. That text is included in the test's results file (.jtr). Tests that use the Done interface request the user to perform keyboard-mouse actions and click Done.

Interactive tests time out if the user does not click Yes-No or Done within a certain amount of time. Timeout values for these tests vary. The timeout value for a test is based on the complexity of the test. A test must be rerun if it times out, perhaps with a different timeout value.

Note - You can use the Pause-Resume button in each interactive test frame to pause the test timer and then work with the test as long as you want.

Some automated interactive tests use the java.awt.Robot class to generate key presses. On some platforms, the delay between key presses is a user-configurable property and the behavior of these automated interactive tests might be affected by the delay between key presses. The user might need to adjust the delay to make the tests execute correctly.

Interactive AWT tests set the size of the test frame to the size of the screen if the screen size is smaller than the size of the test frame.

Some automated interactive tests fail if they are run on low-resolution screens when using the JavaTest harness command-line interface. All components must be visible in the test frame for the robot to interact with them.

Note - Interactive tests that test or use the robot can fail if all components in the test frame are not visible.

If you run an automated test in this situation, the test fails with the following message:

Cannot run automated tests on small screen.
Please set robotAvailable to false and rerun
the tests.

If this occurs, set the robotAvailable configuration value to false and change your answer to the AWT Robot interview question to No. For details about running interactive tests, see 5.10 Interactive Tests.

5.3.4 Configuration Tab Name-Value Pairs

The Configuration tab name-value pairs in Table 5-5 are provided for use with the JavaTest harness test view and Test Environment dialog box when troubleshooting problems with running tests. You can view the configuration values that were used to run a specific test by choosing the Configuration tab in the Test Manager.

For a description of the test view tabs and Test Environment dialog box, see the JavaTest Harness User's Guide: Graphical User Interface included with this release or the JavaTest harness online help.

If you intend to set a configuration value in the command line to run tests, see Chapter 4 for a description of how to obtain the required question-tag names for your configuration.

Table 5-5 lists the name-values pairs displayed in the Configuration tab for the AWT and Swing tests.

Table 5-5 AWT and Swing Test Configuration Tab Name-Value Pairs

Name

Value Description

DISPLAY

Users on X11-based systems must define the $DISPLAY value explicitly in the configuration.

If the value is not set in the configuration, you can set it as a system property by using the -D switch when starting the JavaTest harness.

For example:

java -DDISPLAY=$DISPLAY \ com.sun.javatest.tool.Main

This value is automatically set for you by the script jck/solaris/bin/javatest.

HOME

Users on X11-based systems must define the $HOME value explicitly in the configuration.

If the value is not set in the configuration, you can set it as a system property by using the -D switch when starting the JavaTest harness.

For example:

java -DHOME=$HOME \ com.sun.javatest.tool.Main

This value is automatically set for you by the script jck/solaris/bin/javatest.

platform.isHeadless

Boolean value that indicates whether the system being tested is headless. A headless system is one that does not have a display device, a keyboard, or mouse. If the system is headless, this value must be true. Otherwise, it must be false.

platform.robotAvailable

Boolean value that indicates whether the system being tested supports low-level input control (provided by java.awt.Robot classes). If the system supports the java.awt.Robot classes, the value must be true. Otherwise, it must be false.

5.4 Compiler Tests

Table 5-6 provides the location of the compiler tests and identifies the areas that are tested.

Table 5-6 Compiler Test Information

Test Information

Description or Value

APIs tested

Not applicable for these tests

Test URL

lang

5.4.1 Setup

When rerunning compiler tests, verify that the work area does not contain class files created during a previous run.

The Java Compiler API (JSR 199) provides a set of interfaces that describes the functions provided by a Java compiler and a service provider framework. Because vendors can provide their own implementations of these interfaces, you must run the JCK compiler tests against each available compiler by using all possible interfaces.

You must use the JCK compiler interview to specify how each the tested compiler is run. In the single-VM mode, tests for the available compiler must be run through the Java Compiler API. In the multi-VM mode, tests for the available compiler can be run either through command-line interface or through the Java Compiler API.

Note - If your platform has an alternative compiler or compilers available through the Java Compiler API and a service provider framework, use the interview to specify the compiler that is tested. To do this, set the Default Compiler answer to No and enter the alternative compiler class name in the Compiler Class Name interview question. When the test is run, the harness selects the compiler by its name from the list of available compilers.

5.4.2 Configuration

To enable new language features (such as generics) introduced in Java 2 Platform Standard Edition 5.0, you might be required to answer the Other Options question in each interview. For example, the JDK software compiler requires the -source 1.5 option to enable new language features.

5.4.3 Execution

No special requirements.

5.4.4 Configuration Tab Name-Value Pairs

The Configuration tab name-value pairs in Table 5-7 are provided for use with the JavaTest harness test view and Test Environment dialog box when troubleshooting problems with running tests. You can view the configuration values that were used to run a specific test by choosing the Configuration tab in the Test Manager.

For a description of the test view tabs and Test Environment dialog box, see the JavaTest Harness User's Guide: Graphical User Interface included with this release or the JavaTest harness online help.

If you intend to set a configuration value in the command line to run tests, see Chapter 4 for a description of how to obtain the required question-tag names for your configuration.

Table 5-7 lists the name-values pairs displayed in the Configuration tab for the Compiler tests.

Table 5-7 Compiler Test Configuration Tab Name-Value Pairs

Name

Value Description

Select Compiler

The way to run a compiler. In the multi-VM mode it can be run either through the command-line interface or through the Java Compiler API.

Example Configuration tab value:

Java Compiler API

Java Launcher (only for multi-VM mode and Compiler API)

This is the command used to invoke the Java runtime system used to run your Java compiler.

Example Configuration tab value:

jdk_install_dir/bin/java

Runtime Classpath (only for multi-VM mode and Compiler API)

The way to pass the classpath for the Java runtime system used to run your Java compiler. Can be set either as an environment variable or as a command-line option.

Note - This value determines the subsequent set of name-value pairs.

Classpath Environment Variable (only for multi-VM mode and Compiler API)

The name of the environment variable used to set the classpath.

Example Configuration tab value:

CLASSPATH

Classpath Option (only for multi-VM mode and Compiler API)

The option template for use in setting the classpath.

Example Configuration tab value:

-classpath

Other Environment Variables (only for multi-VM mode and Compiler API)

Other environment variables for Java runtime system used to run your Java Compiler.

Example Configuration tab value:

name1=value1

Other Options

Any other command-line options that must be set for your Java compiler.

Example Configuration tab value:

-source 1.6

Default Compiler

A switch between the default compiler provided by ToolProvider.getSystemJavaCompilerTool() and another compiler made available through the service provider mechanism.

Example Configuration tab value:

No

Compiler Class Name

An alternative compiler class name.

Example Configuration tab value:

com.vendor.Compiler

5.5 CORBA Tests

Table 5-8 provides the location of the CORBA tests and identifies the API that is tested.

Table 5-8 CORBA Test Information

Test Information

Description or Value

Area tested

CORBA API

Test URL

api/org_omg

api/javax_rmi

These tests test IDL to Java library code mapping, ORB features, and the CosNaming name server.

5.5.1 Setup

Before you execute the CORBA tests, you must start the Transient Name Service (TNS). To run network tests, you must also set up a remote host for communication with the CORBA tests during the test run.

Starting the Transient Name Service

Before you execute the tests, you must start the TNS. The TNS is located in the bin directory of the JDK release.

The following commands start the server listening on the default port (900).

    • To start the TNS on the Solaris platform, type the following command:

      jdk/bin/tnameserv

      Note - On the Solaris platform, you must have root access to use port 900.

    • To start the TNS on Win32, type the following command:

      jdk\bin\tnameserv

      You can start the server listening on a different port.

    • To use a port other than the default port, include the -ORBInitialPort flag and a port number in the command used to start the TNS.

      For example, type the following command to use port 1234:

      jdk/bin/tnameserv -ORBInitialPort 1234

    • Use the following command to change the port value in the .jti file so that it reflects the new port number:

      OrbPortID=1234

Setting up the CORBA Distributed Test Run

Many CORBA tests communicate with a remote host during the test run. The remote host consists of a passive agent running on a Sun reference Java virtual machine (reference VM) located on a system other than the one being tested.

Note - The reference VM for the remote agent must be the same version as the VM under test.

Follow these steps to run network tests:

  1. Set up and start the distributed test host.
  2. Copy javatest.jar to the distributed test server.
  3. With javatest.jar on the classpath, start either the GUI or command-line version of the passive agent on the distributed test server.

    For detailed information about starting a JavaTest harness agent, see the JavaTest Agent User's Guide.

    Note - By default, the agent uses port 1908. If that port is not available, you can change it using the -passivePort option. Be sure that the port you use matches the one you specify in the remote.networkAgent configuration value.

  4. Run the CORBA tests.

5.5.2 Configuration

A number of the CORBA tests use a distributed framework for testing the CORBA communications.

5.5.2.1 Distributed Tests

Distributed tests validate API functionality while the test platform is connected to a remote host. One part of the distributed test runs as usual on the platform under test and the other part of the test runs on a remote host using a passive agent running on a reference VM. For these tests to run, use each interview and its instructions to configure the JavaTest harness for using a passive agent. After the interview is complete, the passive agent must be started on the remote host as described in Setting up the CORBA Distributed Test Run.

5.5.3 Execution

No special requirements.

5.5.4 Configuration Tab Name-Value Pairs

The Configuration tab name-value pairs in Table 5-9 are provided for use with the JavaTest harness test view and Test Environment dialog box when troubleshooting problems with running tests. You can view the configuration values that were used to run a specific test by choosing the Configuration tab in the Test Manager.

For a description of the test view tabs and Test Environment dialog box, see the JavaTest Harness User's Guide: Graphical User Interface included with this release or the JavaTest harness online help.

If you intend to set a configuration value in the command line to run tests, see Chapter 4 for a description of how to obtain the required question-tag names for your configuration.

Table 5-9 lists the name-values pairs displayed in the Configuration tab for the CORBA tests.

Table 5-9 CORBA Test Configuration Tab Name-Value Pairs

Name

Value Description

ORBHost

The name of a host or machine running the TNS. You can use the alias localhost to specify the currently running host.

Example Configuration tab value:

localhost

OrbPortID

The port number listened to by the TNS.

5.6 Distributed Tests

Many network, Java APIs for XML Web Services (JAX-WS), Java Debug Wire Protocol (JDWP), and Java Management Extensions (JMXTM API) Remote tests communicate with a remote host during the test run. The remote host consists of a passive agent running on one of the Sun reference VMs on a system other than the one being tested.

Note - The reference VM for the remote agent must be the same version as the VM under test.

5.6.1 Setup

Before you can run the distributed tests, you must set up a remote host with a passive agent.

Setting up the Distributed Tests Run
  1. Disable network data and packet filtering software.

    This requirement includes Personal Firewall provided with Windows XP.

  2. Set up and start the distributed test host.
  3. Verify that the test suite installation directory is reachable from a remote computer through the network drive or NFS mount.

    The JAX-WS tests must use files located in the test suite installation directory.

  4. Start the passive agent on the distributed test server.

    Note - The passive agent for distributed tests must be run with the JCK security policy in effect. The reference VM running the passive agent must be started with the java.security.policy set. For example, the following VM option must be specified when running the passive agent:

    -Djava.security.policy=JCK/lib/jck.policy

    1. Copy javatest.jar to the distributed test server.
    2. With javatest.jar on the classpath, start either the GUI or command-line version of the passive agent from a command prompt.

      See the JavaTest Agent User's Guide for detailed information about starting JavaTest harness agents.

      Note - By default the agent uses port 1908. If that port is not available, you can change it using the -passivePort option. Be sure that the port you use matches the one you specify in the remote.networkAgent configuration value.

    Refer to 5.6.2 Configuration for information about configuring the JavaTest harness for using a passive agent to run Distributed Tests.

5.6.2 Configuration

Many network and JDWP tests use a distributed framework for testing the network API and the JDWP implementation. The distributed tests validate technology functionality while the test platform is connected to a remote host. One part of the distributed test runs on the platform under test and the other part of the test runs on a remote host using a passive agent. Always run the agent on a reference VM.

The JAX-WS tests use files from the test suite installation directory. To run JAX-WS tests, you must use a map file on a Remote Agent to map the test suite installation directory file syntax between systems. Refer to Appendix B, Detailed Examples, the JavaTest Agent User's Guide, or the JavaTest harness online help for detailed instructions about creating and using map files.

You must complete the Remote Agent section of each interview to configure the JavaTest harness for using a passive agent. The Remote Agent section of each interview begins with the question titled "Remote Agent Configuration." After the interview is completed, start the passive agent on the remote host as described in the JavaTest Agent User's Guide.

If you have problems running the tests with the passive agent, use Table 5-10 to verify the configuration settings of the agent in the JavaTest harness.

5.6.3 Execution

See 5.11 JAX-WS Mapping Tests, 5.13 JDWP Tests, and 5.25 Network Testsfor detailed information about specific test execution.

5.6.4 Configuration Tab Name-Value Pairs

The Configuration tab name-value pairs in Table 5-10 are provided for use with the JavaTest harness test view and Test Environment dialog box when troubleshooting problems with running tests. You can view the configuration values that were used to run a specific test by choosing the Configuration tab in the Test Manager.

If you have problems running the tests with the passive agent, use Table 5-10 to verify the name-value settings of the agent in the JavaTest harness.

For a description of the test view tabs and Test Environment dialog box, see the JavaTest Harness User's Guide: Graphical User Interface included with this release or the JavaTest harness online help.

If you intend to set a configuration value in the command line to run tests, see Chapter 4 for a description of how to obtain the required question-tag names for your configuration.

Table 5-10 lists the name-values pairs displayed in the Configuration tab for the Distributed tests.

Table 5-10 Distributed Test Configuration Tab Name-Value Pairs

Name

Value Description

remote.networkAgent

Specifies the parameters required to connect with the agent running on the remote host:

-host host-name

Contacts the agent on host host-name.

The following parameter is required:

-port port-number

Contacts the agent on port port-number. If omitted, the default port (1908) is used.

The following parameter is optional:

-classpath path

Loads the classes to be executed on the remote host from path. If omitted, the agent loads classes from the agent's system classpath

Example Configuration tab value:

-host localhost \

-classpath $testClassDir:\

$testSuiteRootDir/.../classes

5.7 Extra-Attribute Tests

Table 5-11 provides the location of the Extra-Attribute (ATR) tests and identifies the areas that are tested.

Table 5-11 Extra-Attribute Test Information

Test Information

Description or Value

Area tested

Additional attributes in class files

Test URLs

vm/classfmt/atr

5.7.1 Setup

Because these tests use C code, it is not possible to define their compilation in a platform-independent way. Therefore, you must compile these tests before running them. These files must be compiled into a library named jckatr for loading using the method System.loadLibrary ("jckatr"). To build thejckatr library, compile the file jck/src/share/lib/atr/jckatr.c, that contains a list of #include statements that refer to other files in the jck/tests directory.

When building the jckatr library, if the library is linked dynamically, you must set up a platform-dependent system environment variable such as LD_LIBRARY_PATH on the Solaris platform, or PATH on Win32 to load the jckatr libraries.

See Building jckatr.dll for Win32 Systems, Building libjckatr.so With C Compiler for Solaris Platform, and Building libjckatr.so With Gnu C for Solaris Platformfor the procedures required to build the jckatr library on Win32 systems and the Solaris platform.

Building jckatr.dll for Win32 Systems
  • Use the command lines in Example 5-1 to build the jckatr.dll library for Win32 systems using the Microsoft Visual C++ (MSVC++) compiler.

    Substitute the exact JCK and destination paths for the strings jck and dest.

Example 5-1 Using MSVC++ Compiler to Build jckatr.dll 
cl /LD /MD /TP /DWIN32 /DNDEBUG /D_WINDOWS /D_USRDLL \
/D_WINDLL /D_AFXDLL /Ijck /Fodest\jckatr.obj \
jck\src\share\lib\atr\jckatr.c \
/link /PDB:NONE /DLL /DEF:jck\src\share\lib\atr\jckatr.def \
/OUT:dest\jckatr.dll
5.7.1.1 Command-Line Options for MSVC++ Compiler

Table 5-12 contains the command-line options used to build the jckatr.dll library for Win32 systems.

Table 5-12 Command-Line Options for MSVC++ Compiler

Option

Description

cl

The MSVC++ compiler.

/LD /MD

Create .DLL and link it with MSVCRT.LIB (multi-threaded runtime).

/TP

Compile all files as C++ sources.

/DWIN32

Define WIN32 for C preprocessor.

/D_WINDOWS

Define _WINDOWS for C preprocessor.

/Ijck

Add the directory to include search path.

/Fodest

Specify the intermediate object file.

jck\src\share\lib\atr\jckatr.c

Input file.

/link

Linker options follow.

/PDB:NONE

Do not create a Program Database.

/DLL

Build a dll.

/DEF:jck\src\share\lib\atr\jckatr.def

Module-definition file.

/OUT:dest\jckatr.dll

Specify the output file name. dest represents the path of the destination directory.

Note - To use the MSVC++ compiler, you might need to set up some environment variables, such as INCLUDE, LIB, and PATH. Use the file vcvars32.bat located in the installed bin directory (from MSVC++) to set up environment variables.

Building libjckatr.so With C Compiler for Solaris Platform
  • Use the command lines from Example 5-2 to build the library for the Solaris platform.

    Substitute the exact JCK and destination paths for the strings jck and dest.

Example 5-2 Using C Compiler to Build libjckatr.so 
cc -G -KPIC -o dest/libjckatr.so -Ijck jck/src/share/lib/atr/jckatr.c
5.7.1.2 Command-Line Options for the Solaris Platform C Compiler

Table 5-13 contains the command-line options used to compile the test files for the Solaris platform.

Table 5-13 Command-Line Options for the Solaris Platform C Compiler

Option

Description

cc

C compiler.

-G

Generate a shared library.

-KPIC

Generate position-independent code.

-Ijck

Add the JCK directory to the include search path.

-o dest/libjckatr.so

Specify the output file name. dest represents the path of the destination directory.

jck/src/share/lib/atr/jckatr.c

Input file.
Building libjckatr.so With Gnu C for Solaris Platform
  • Use the command lines from Example 5-3 to build the library using the Gnu C compiler for the Solaris platform.

    Substitute the exact JCK and destination paths for the strings jck and dest.

Example 5-3 Using Gnu C Compiler to Build the libjckatr.so 
gcc -fPIC -shared -o dest/libjckatr.so -Ijck jck/src/share/lib/atr/jckatr.c
5.7.1.3 Command-Line Options for the Gnu C Compiler for the Solaris Platform

Table 5-14 contains the command-line options used to build the library using the Gnu C compiler for the Solaris platform.

Table 5-14 Command-Line Options for the Gnu C Compiler for the Solaris Platform

Option

Description

gcc

Gnu C Compiler.

-fPIC

Emit position-independent code, suitable for dynamic linking.

-shared

Produce a shared object.

-o dest/libjckatr.so

Specify the output file name. dest represents the path of the destination directory.

-Ijck

Add the JCK directory to the include search path.

jck/src/share/lib/atr/jckatr.c

Input file.

5.7.2 Configuration

No special requirements.

5.7.3 Execution

No special requirements.

5.7.4 Configuration Tab Name-Value Pairs

The Configuration tab name-value pairs in Table 5-15 are provided for use with the JavaTest harness test view and Test Environment dialog box when troubleshooting problems with running tests. You can view the configuration values that were used to run a specific test by choosing the Configuration tab in the Test Manager.

For a description of the test view tabs and Test Environment dialog box, see the JavaTest Harness User's Guide: Graphical User Interface included with this release or the JavaTest harness online help.

If you intend to set a configuration value in the command line to run tests, see Chapter 4 for a description of how to obtain the required question-tag names for your configuration.

Table 5-15 lists the name-values pairs displayed in the Configuration tab for the extra-attribute tests.

Table 5-15 Extra-Attribute Test Configuration Tab Name-Value Pairs

Name

Value Description

platform.nativeCodeSupported

If your system supports native code, this value is true. This value signifies that the VM under test provides support for loading native code. If your system does not provide support for loading native code, this value must be false.

PATH

LD_LIBRARY_PATH

The .jti file created by the Configuration Editor must include any necessary platform-specific variables used to identify the path to the library file. On Win32 systems, the variable is PATH. On the Solaris platform, the variable is LD_LIBRARY_PATH.

If you execute your tests using the JavaTest harness agent, you must set the platform-specific variables (PATH or LD_LIBRARY_PATH) before you start the agent. See jck/win32/bin/javatest for a useful script.

5.8 Floating-Point Tests

Table 5-16 provides the location of the floating-point tests and identifies the areas that are tested.

Table 5-16 Floating-Point Test Information

Test Information

Description or Value

Areas tested

Virtual machine

Language

Test URLs

vm/fp

lang/FP

JCK includes several tests for floating-point calculations. Extended floating-point formats might be used to represent the values of float and double data types in the default mode of calculations. The platform-specific parameters of these extended floating-point formats are required for some of the tests to execute successfully.

5.8.1 Setup

No special requirements.

5.8.2 Configuration

No special requirements.

5.8.3 Execution

No special requirements.

5.8.4 Configuration Tab Name-Value Pairs

The Configuration tab name-value pairs in Table 5-17 are provided for use with the JavaTest harness test view and Test Environment dialog box when troubleshooting problems with running tests. You can view the configuration values that were used to run a specific test by choosing the Configuration tab in the Test Manager.

For a description of the test view tabs and Test Environment dialog box, see the JavaTest Harness User's Guide: Graphical User Interface included with this release or the JavaTest harness online help.

If you intend to set a configuration value in the command line to run tests, see Chapter 4 for a description of how to obtain the required question-tag names for your configuration.

Table 5-17 lists the name-values pairs displayed in the Configuration tab for the floating-point tests.

Table 5-17 Floating-Point Test Configuration Tab Name-Value Pairs

Name

Value Description

hardware.xFP_ExponentRanges

Four numbers that describe the ranges of exponents that can be represented in extended-exponent formats of floating-point values. The numbers are ordered and separated by a colon (:). The first two numbers denote the minimum and maximum exponent representable in extended-exponent format for the type float. The last two numbers denote the minimum and maximum exponent representable in extended-exponent format for the type double.

The following example describes parameters for the Intel x86 80-bit float and double formats. Both formats provide 15 bits for exponents.

Example Configuration tab value:

-16382:16383:-16382:16383

If the Java technology implementation under test does not use extended-exponent floating-point formats in non-strictfp calculations, the value must be equal to the parameters of standard floating-point formats shown in the following example.

Example Configuration tab value:

-126:127:-1022:1023

For JCK runtime, the default value in each interview corresponds to the standard formats of the Java programming language float and double types. If your implementation uses extended floating-point formats, you must set this value in the configuration.

For JCK compiler, the value set in each interview must be appropriate for the JRE implementation used to execute the resulting class files. Sun provides reference implementations for the SPARC processor architecture and for the Intel x86 processor architecture. The default configuration value in each interview is for the SPARC processor reference architecture. If you use a reference implementation for the Intel x86 processor architecture, you must also set the value for the Intel x86 reference architecture in the JCK configuration file.

5.9 ImageIO Tests

Table 5-18 provides the location of the Java ImageIO API tests and identifies the area that is tested.

Table 5-18 ImageIO Test Information

Test Information

Description or Value

API tested

javax.imageio

Test URLs

api/javax_imageio/ImageIO

5.9.1 Setup

Before using a browser to run Java ImageIO API tests, you must add the ImageIO-resources.jar file located at URL-TO-JCK-ROOT/tests/api/javax_imageio/ImageIO to the archive attribute in the HTML code used to launch the agent.

Example 5-4 Applet Code to Launch a JavaTest Agent 
<applet
code="com.sun.javatest.agent.AgentApplet"
codebase="[URL-TO-JCK-ROOT]/classes"
archive="../lib/javatest.jar,
../tests/api/javax_imageio/ImageIO/ImageIO-resources.jar"
width=600
height=600 >
</applet>

See Appendix B for detailed information about how to use the JavaTest harness with a browser (Netscape NavigatorTM and JavaPlug-In software) and an agent to run JCK tests.

5.9.2 Configuration

No special requirements.

5.9.3 Execution

No special requirements.

5.9.4 Configuration Tab Name-Value Pairs

None.

5.10 Interactive Tests

Interactive tests require user interaction. All interactive tests in the JCK test suite are executed at one time, irrespective of the fact that they belong to different test API areas.

The following JCK test areas include interactive tests:

  • api/java_awt/interactive

  • api/javax_print/interactive

  • api/javax_sound/interactive

  • api/javax_swing/interactive/

Interactive tests have been developed using two kinds of user interfaces:

  • Yes-No interface — Tests that use the Yes-No interface request the user to perform a visual verification and keyboard-mouse actions, and to click Yes or No to declare whether the test passed or failed. If the user clicks No in the case of a failed test, the user is prompted to enter text that describes the failure. That text is included in the test's results file (.jtr).

  • Done interface — Tests that use the Done interface request the user to perform keyboard-mouse actions and click Done.

5.10.1 Setup

Because interactive tests require keyboard and mouse input, you might decide to run them separately and not batched with the rest of the test suite.

Interactive tests contain the interactive or robot keyword. You can use the keywords field in the JavaTest Configuration Editor to filter or include interactive tests in a test run.

  • interactive — All interactive tests contain this keyword. Use the interactive keyword to include interactive tests in a test run. Use the !interactive expression to exclude interactive tests from a test run.

  • robot — Some AWT interactive tests contain the robot keyword. Use robot keyword if your platform supports the option to run interactive tests without human interaction, which is done by using the java.awt.Robot class. Tests that use the robot can be selected or deselected by specifying the robot keyword in the configuration. See 5.3 AWT and Swing Tests for more information about using the robot keyword.

For more information about using keywords in the configuration, see Chapter 4.

Running the interactive tests separately reduces the time required to find the tests that use the interactive or robot keywords. To run the interactive tests separately, specify in the configuration which interactive tests to run (for example, AWT and Swing, Printing, and Sound tests or just some of these). See Chapter 4 for detailed information.

Interactive tests time out if the user does not click Yes-No or Done within a certain amount of time. Timeout values for these tests vary. The timeout value for a test is based on the complexity of the test. A test must be rerun if it times out, perhaps with a different timeout value.

Note - You can use the Pause-Resume button in each interactive test frame to pause the test timer and then work with the test as long as you want.

For test-specific information, see respectively:

5.10.2 Configuration

For test-specific information, see respectively:

5.10.3 Execution

For test-specific information, see respectively:

5.10.4 Configuration Name-Pair Values

For test-specific information, see respectively:

5.11 JAX-WS Mapping Tests

Two kinds of JAX-WS tests are included in the devtools compiler test suite.

  • Java-to-WSDL mapping tests do mapping .java classes onto WSDL files

  • WSDL-to-Java mapping tests do mapping WSDL files with binding files onto .java classes

TABLE 5–21 provides the location of the JAX-WS mapping tests and identifies the areas that are tested.

Table 5-19 JAX-WS Mapping Test Information

Test Information

Description or Value

API tested

Not applicable. Tests for JAX-WS API are located in the JCK runtime test suite.

Test URLs

jaxws

5.11.1 Setup

Executing JAX-WS mapping tests is implementation-specific. Depending on whether you choose to execute in multi-VM or in single-VM mode, you must provide either a wrapper script or a wrapper class for JCK to do JAX-WS mapping.

If you choose to start a new instance of the product from a command line each time a new test is executed, the JCK invokes the JAX-WS mapping as a separate process for each test. The mapping and tests will run in multi-VM mode.

For detailed instructions required to provide and use a wrapper script to execute a JAX-WS mapping in this test environment, see 5.11.1.1 Running Java-to-WSDL Mapping in Multi-VM Mode and 5.11.1.2 Running WSDL-to-Java Mapping in Multi-VM Mode.

If you choose not to start a new instance of the product from a command line each time a new test is executed, all mapping will be done and tests are executed in a single process, the agent's VM. For detailed instructions required to provide and use a wrapper class to execute a JAX-WS mapping in this test environment, see 5.11.1.3 Running Java-to-WSDL Mapping in Single-VM Mode and 5.11.1.4 Running WSDL-to-Java Mapping in Single-VM Mode.

5.11.1.1 Running Java-to-WSDL Mapping in Multi-VM Mode

In multi-VM mode, Java-to-WSDL mapping is invoked as a separate process for each test. The JCK invokes the wrapper script for mapping using the java.lang.Runtime.exec(String[] cmdarray, String[] envp) method, where cmdarray is the following form:

[environment-variables] command -cp classpath -d out-dir java-files

Optional parameters are enclosed in square brackets ([]). The devtools compiler test suite assumes that with the -d option, an output directory is specified and the .java classes to map are specified at the end of command string.

The following variables are included in the command string:

  • environment-variables - Environment variables if required can be specified in the Other environment variables question of Configuration Editor.

  • command - The name of the wrapper script that does Java-to-WSDL mapping.

  • classpath - The classpath constructed by the devtools test suite.

  • out-dir - The directory in which the generated files are placed.

  • java-files - The .java class files to map.

The devtools test suite provides two sample scripts that work for the reference JAX-WS Java-to-WSDL mapping. You can use the following scripts to develop scripts for other JAX-WS implementations:

  • solaris/bin/wsgen.sh (or linux/bin/wsgen.sh) - A ksh script used to run tests with the reference JAX-WS mapping tool on Solaris or Linux platforms.

  • win32/bin/wsgen.bat - A Windows batch script used to run tests with the reference JAX-WS mapping tool on Windows platforms. This script is similar to the solaris/bin/wsgen.sh script.

5.11.1.2 Running WSDL-to-Java Mapping in Multi-VM Mode

In multi-VM mode, WSDL-to-Java mapping is invoked as a separate process for each test. The JCK invokes the wrapper script for mapping by using the java.lang.Runtime.exec(String[] cmdarray, String[] envp) method, where cmdarray is the following:

[environment-variables] command -cp classpath [-b binding-file] -d out-dir wsdl-files

Optional parameters are enclosed in square brackets ([]). The devtools compiler test suite assumes that option -b denotes binding file, with -d option output directory is specified and .java classes to map are specified at the end of command string.

The following variables are included in the command string:

  • environment-variables - Environment variables if required can be specified in the Other environment variables question of Configuration Editor.

  • command - The wrapper script that do WSDL-to-Java mapping.

  • classpath - The classpath is constructed by JCK-devtools test suite.

  • binding-file - The binding file. Use of more than one binding file is allowed. Each binding file must be preceded by a -b option.

  • out-dir - The directory in which the generated files are placed.

  • wsdl-files - The WSDL files to map.

The devtools test suite provides two sample scripts that work for the reference WSDL-to-Java mapping. You can use the following scripts to develop scripts for other JAX-WS implementations:

  • solaris/bin/wsimport.sh (or linux/bin/wsimport.sh) - A ksh script. Used to run tests with the reference JAX-WS mapping tool on Solaris or Linux platforms.

  • win32/bin/wsimport.bat - Windows batch script. Used to run tests with the reference JAX-WS mapping tool on Windows platforms. This script is similar to the solaris/bin/wsimport.sh script.

5.11.1.3 Running Java-to-WSDL Mapping in Single-VM Mode

In single-VM mode, all invocations of a Java-to-WSDL mapping are made from the JavaTest agent running in the same VM. A wrapper class for the schema compiler must implement the following com.sun.jck.lib.WSGenTool interface.

package com.sun.jck.lib;
public interface WSGenTool {
int generate(String sei, File outDir, PrintStream out, PrintStream err);
}
public int compile_method(String[] args, java.io.PrintStream out,
java.io.PrintStream err)

Java-to-WSDL mapping should be accomplished during the invocation of the generate method.

  • sei - .java file to be mapped

  • outDir - Output directory where wsdl is generated

  • out - Output stream for logging

  • err - Error stream for logging

The JCK includes the following sample class that is fully compatible with Sun's reference implementation and that can be used for Java-to-WSDL mapping:

com.sun.jck.lib.WSGen

5.11.1.4 Running WSDL-to-Java Mapping in Single-VM Mode

In single-VM mode, all invocations of WSDL-to-Java mapping are made from the JavaTest agent running in the same VM. A wrapper class for the schema compiler must implement the following com.sun.jck.lib.WSImportTool interface:

package com.sun.jck.lib;
public interface WSImportTool {
int compile(String{} wsdlFiles, String[] xmlFiles, File outDir, 
PrintStream out, PrintStream err);
}

WSDL-to-Java mapping should be accomplished during invocation of compile method.

  • wsdlFiles - Array of strings containing wsdl files

  • xmlFiles - Array of strings containing binding files

  • outDir - Output directory where .java files will be generated

  • out - Output stream for logging

  • err - Error stream for logging

The JCK includes the following sample class that is fully compatible with Sun's reference implementation and that can be used as a WSDL-to-Java class:

com.sun.jck.lib.WSImport.

5.11.2 Configuration

JAX-WS tests use files from test suite installation directory. To run JAX-WS tests you must use a map file on a Remote Agent to map the test suite installation directory file syntax between systems. Refer to the JavaTest Agent User's Guide, the JavaTest Harness User's Guide: Graphical User Interface, or the JavaTest harness online help for detailed instructions about creating and using map files.

5.11.3 Execution

No special requirements.

5.11.4 Configuration Tab Name-Value Pairs

None.

5.12 JDBC Technology RowSet Tests

The JCK includes tests for implementation classes of five standard Java Database Connectivity (JDBCTM) technology RowSet interfaces: CachedRowSet, JdbcRowSet, WebRowSet, FilteredRowSet, and JoinRowSet.

Table 5-20 provides the location of the JDBC technology RowSet tests and identifies the areas that are tested.

Table 5-20 JDBC TechnologyRowSet Test Information

Test Information

Description or Value

Area tested

Rowset implementation classes

Test URLs

api/javax_sql/rowset/impl

5.12.1 Setup

If you want to test your own rowset implementations, you must implement and compile the specific factory class that is used to create the rowsets. The class must have the public default constructor and implement the javasoft.sqe.tests.api.javax.sql.rowset.impl.RowSetFactory interface located at jck/src/share/classes/javasoft/sqe/tests/rowset/util/RowSetFactory.java.

This interface contains methods for creating the rowset instances. The method used must return a newly created instance or instances each time it is invoked.

For example, to compile the custom factory with Sun's Java compiler, use the following command:

jdk/bin/javac -cp jck/classes -d out CustomRowSetFactory.java

Where:

  • jdk - Path to Sun's JDK software

  • jck/classes - Path to the TCK's JDBC technology RowSet classes

  • out - Classes output directory

  • CustomRowSetFactory.java - Factory provided by the user

The location of the compiled factory class or classes must be added to the JCK classpath. For multi-VM mode, you must add the location in the answer to the Additional Classpath interview question. For a single-VM mode, you must add the corresponding classpath to the JavaTest agent invocation command.

For testing reference implementation of rowsets the javasoft.sqe.tests.api.javax.sql.rowset.impl.RowSetFactoryImpl is used. This class is located in the jck/classes directory.

5.12.2 Execution

No special requirements.

5.12.3 Special Configuration Steps

No special requirements.

5.12.4 Configuration Tab Name-Value Pairs

The Configuration tab name-value pairs in Table 5-21 are provided for use with the JavaTest harness test view and Test Environment dialog box when troubleshooting problems with running tests. You can view the configuration values that were used to run a specific test by choosing the Configuration tab in the Test Manager.

For a description of the test view tabs and Test Environment dialog box, see the JavaTest Harness User's Guide: Graphical User Interface included with this release or the JavaTest harness online help.

If you intend to set a configuration value in the command line to run tests, see Chapter 4 for a description of how to obtain the required question-tag names for your configuration.

Table 5-21 lists the name-values pairs displayed in the Configuration tab for the JDBC technology Rowset tests.

Table 5-21 JDBC Technology Rowset Tests Configuration Tab Name-Value Pairs

Name

Value Description

platform.rowSetFactory

The fully qualified name of the factory class used for creating the rowsets.

5.13 JDWP Tests

The JCK includes tests for Java Debug Wire Protocol (JDWP). JDWP is the protocol used for communication between a debugger and the VM that it debugs, such as a target VM running a program.

Table 5-22 provides the location of the JDWP tests and identifies the areas that are tested.

Table 5-22 JDWP Test Information

Test Information

Description or Value

Area tested

Java Debug Wire Protocol

Test URLs

vm/jdwp

5.13.1 Setup

Before you can run JDWP tests, you must set up the test system. The following procedures are required to establish a transport class and location for the remote agent to load classes from the JavaTest harness.

Setting up a Test System to Run JDWP Tests
  1. Provide TransportService class.

    A JDWP implementation might be represented either as a Java Virtual Machine Tool Interface (JVM TI) agent or as an integral part of a VM. JDWP tests use a pluggable transport mechanism for establishing a connection between debuggers and the JDWP implementation. The JCK provides a Java technology TCP socket-based transport. If you need a non-TCP-based transport for testing a JDWP implementation configuration, you must provide your own transport class.

    The transport class provided must be a subclass of the com.sun.jdi.connect.spi.TransportService abstract class.

    All required source files of .java classes from package com.sun.jdi.connect.spi are located in the following directory:

    jck/src/share/classes/javasoft/sqe/jck/lib/jpda/jdi/

    If you provide your own transport class, you must use either Sun's Java compiler or another certified compiler to compile it on one of the reference platforms.

    Compiled class files of com.sun.jdi.connect.spi are located in corresponding subdirectories of the jck/classes directory.

    Example compilation of provided transport class (using JDK software on the Solaris platform):

    jdk/bin/javac -d . -classpath jck/classes YourTransportServiceClass.java

  2. Set up a transport class location.

    If you have configured a remote agent to load classes from the JavaTest harness, copy the compiled transport class into a directory accessible from the system where you start the JavaTest harness. Each interview asks you to specify a directory or a .jar file where the class can be found by the JavaTest harness. Otherwise, you must ensure that the transport class is in the remote agent's classpath.

  3. Set up JDWP distributed test run.

    All JDWP tests communicate with a remote host during the test run. The remote host consists of a passive agent running on one of the Sun reference VMs on a system other than the one being tested.

    Note - The reference VM for the remote agent must be the same version as the VM under test.

    1. Set up and start the distributed test host.
    2. Start the passive agent on the distributed test server:
      1. Copy javatest.jar to the distributed test server.
      2. With javatest.jar on the classpath, start either the GUI or command-line version of the passive agent.
      3. If the remote agent is configured to not load classes from the JavaTest harness and you provide your own transport class, you must provide that compiled transport class in the agent's classpath.

    See the JavaTest Agent User's Guide for detailed information about starting a JavaTest harness agent.

    Note - If you only run the JDWP tests, you might start the remote agent on the system where the tested Java technology-based application is executed. If you run both JDWP and network API tests, you must start the remote agent on a system other than the one being tested. If the provided transport class only works on a specific platform, you might start the remote agent on that platform only to execute the JDWP tests.

5.13.2 Configuration

JDWP tests are distributed tests that validate JDWP functionality while the test platform is connected to a remote host. Normally, one part of a distributed test runs on the platform under test and the other part of the test runs on a remote host using a passive agent running on a reference VM. To run these tests, use each interview to configure the JavaTest harness for using a passive agent. After you complete the configuration, start the passive agent on the remote host as described in 5.13.1 Setup.

Note - In some cases, the remote agent might be started on a machine if it is not running the reference VM. See 5.13.1 Setup for the description of this exception.

5.13.3 Execution

The JDWP tests are distributed tests. Debuggers are executed on the remote JavaTest agent. Debuggees are executed with the activated JDWP implementation on the tested platform.

The JDWP and the TransportService class specifications do not require restoring the JDWP transport connection after the debugging session ends. JDWP implementations might or might not start listening or attaching to debuggers after the previous debugging session is completed.

If the JCK is configured to execute tests in single-VM mode and the tested JDWP implementation does not restore connections after a debugging session ends, you must run each JDWP test separately. After each JDWP test completion, you must take the following actions on the tested platform with the activated JDWP implementation:

  1. Kill the JavaTest agent process running the JavaTest harness agent.

  2. Restart the JavaTest agent for execution of the next test.

The debugging parts of JDWP tests operate with timeout values defined by JavaTest harness time factor set in the interview. You must increase the time factor value in the interview if you experience test timeout problems on slow tested platforms.

Activating the JDWP implementation in a tested runtime might significantly affect non-JDWP JCK tests execution, therefore only JDWP tests must be executed on a tested runtime with activated JDWP implementation.

In multi-VM mode, additional settings are not required. The JavaTest harness passes JDWP-specific options to tested VMs when the jdwp keyword is in the test description.

However, in single-VM mode, only JDWP tests must be executed for testing JDWP implementation. Use keyword-based selection criteria (!jdwp) to run all but JDWP JCK tests. Use keyword-based selection criteria (jdwp) in addition to standard keyword selection criteria to run only JDWP JCK tests in single-VM mode.

5.13.4 Configuration Tab Name-Value Pairs

The Configuration tab name-value pairs in Table 5-23 are provided for use with the JavaTest harness test view and Test Environment dialog box when troubleshooting problems with running tests. You can view the configuration values that were used to run a specific test by choosing the Configuration tab in the Test Manager.

For a description of the test view tabs and Test Environment dialog box, see the JavaTest Harness User's Guide: Graphical User Interface included with this release or the JavaTest harness online help.

If you intend to set a configuration value in the command line to run tests, see Chapter 4 for a description of how to obtain the required question-tag names for your configuration.

Table 5-23 lists the name-values pairs displayed in the Configuration tab for the JDWP tests.

Table 5-23 JDWP Test Configuration Tab Name-Value Pairs

Name

Value Description

platform.jdwpSupported

Boolean value that indicates whether a JDWP implementation is provided for testing. If a JDWP implementation is provided, this value must be true.

jdwpConnectorType

Tested JDWP implementation configuration provides that the JDWP implementation either attaches or listens for connections from debuggers.

The jdwpConnectorType value defines the debugger attaching-listening mode. If the tested JDWP implementation configuration provides that JDWP implementation listens for connections from debuggers, the value of jdwpConnectorType is attaching. Otherwise, it is listening.

jdwpTransportClass

The jdwpTransportClass defines the TransportService implementation class used by debuggers for establishing connection with tested JDWP implementation.

jdwpTransportClassDir

If you provide your own TransportService class implementation and the remote agent is configured to load classes from the JavaTest harness, jdwpTransportClassDir defines a directory or JAR file used by the JavaTest harness for loading your transport class.

The jdwpTransportClassDir value has the following syntax:

pathSeparator directory

In this syntax, pathSeparator is a path separator string specific for the system where the JavaTest harness runs. For example, if you run the JavaTest harness on a Windows system, it is a semicolon (;) and on a Solaris platform it is a colon (:).

In this syntax, directory is either the directory or the JAR file used by the JavaTest harness to search for your transport class.

jdwpTransportAddress

Transport-specific string that defines the address that test debuggers should use for establishing connections with JDWP implementation. For example, in the JCK TCP socket-based transport class, the address has the format:

host:port number

In this syntax, host and port number define host and port number to connect to the JDWP implementation. If JDWP tests are configured for debuggers to listen for connections from JDWP implementation, jdwpTransportAddress is port number, the int value representing the port number for the tests' debuggers to listen for connections from the JDWP implementation.

VMSuspended

Boolean value that indicates whether or not the target VM with the activated JDWP implementation is suspended when initialized. If the VM is suspended, this value must be true.

platform.MultiVM

Boolean value that indicates whether or not the JCK is configured to execute tests in multi-VM mode.

jdwpOpts

Defines the Java platform command-line options specified in the tested command line used to activate JDWP and define the tested JDWP implementation configuration. This value is defined only if the JCK is configured to execute tests in multi-VM mode (such as platform.multiJVM is true). If you execute tests in single-VM mode, specify these options in the JavaTest harness agent start command line.

5.14 JMX API Advanced Dynamic Loading Tests

Table 5-24 provides the location of Advanced Dynamic Loading tests for Java Management Extensions (JMX) API and identifies the area that is tested.

Table 5-24 JMX API Advanced Dynamic Loading Test Information

Test Information

Description or Value

Area tested

JMX API, Advanced Dynamic Loading

Test URLs

api/javax_management/loading

5.14.1 Setup

The JMX API tests for advanced dynamic loading use C code to check loading of native libraries and cannot be compiled in a platform-independent way. Before running the JMX API tests, you must manually make the libraries for the platforms that you are using. If your implementation supports loading native libraries from JAR files, you must prepare two JAR files that contain the native libraries compiled for your platform.

Setting up JMX API Tests on a Platform
  1. Copy HTML and JAR files from jck/tests/api/javax_management/loading/data to a location accessible during the test run.

    This step is optional if you are running tests on one platform. See Copying Required HTML and JAR Files for detailed instructions.

  2. Make systemInfo, jmxlibid, and genrandom libraries.

    See Making systemInfo, jmxlibid, and genrandom Libraries for detailed instructions.

  3. Put systemInfo library into dest/archives/MBeanUseNativeLib.jar.

    See Updating res-dest/archives/MBeanUseNativeLib.jar on the Solaris Platform and Updating res-dest/archives/MBeanUseNativeLib.jar on Win32 Systems for detailed instructions.

  4. Create a new dest/archives/OnlyLibs.jar file containing jmxlibid library. See Creating res-dest/archives/OnlyLibs.jar on the Solaris Platform and Creating res-dest/archives/OnlyLibs.jar on Win32 Systems for detailed instructions.

    Note - In the following examples, jck represents the JCK path (for example, /java/re/jck60/JCK-runtime-60), dest represents the destination path (for example, /java/re/jck60/JCK-runtime-60/lib or /tmp/jmxresources), java represents the path of the reference JDK software for the particular platform (for example, /java/re/jdk60/solaris-sparc), and res-dest represents the directory where you copy HTML and JAR files at the first step (for example, /tmp/work/solaris-MultiVM).

Copying Required HTML and JAR Files
  • Copy HTML and JAR files from jck/tests/api/javax_management/loading/data to a location accessible during the test run.

    This is required if you use the test suite to run the tests on various platforms. Each platform has a different native library. For example, to copy resources for JMX API tests on a Solaris platform, use:

    cp -r jck/tests/api/javax_management/loading/data/* res-dest

    This directory contains the library sources in the archives/src subdirectory. This directory is not needed for the test run. Do not copy it or remove it from the destination directory.

Making systemInfo, jmxlibid, and genrandom Libraries
  1. Compile the systemInfo, jmxlibid, and genrandom libraries.

    See Compiling libsystemInfo.so, libjmxlibid.so, and libgenrandom.so for the Solaris Platform for instructions on compiling for the Solaris platform.

    See Compiling libsystemInfo.so, libjmxlibid.so, and libgenrandom.so for the Solaris Platform Using Gnu C for instructions on using the Gnu C compiler when compiling for the Solaris platform.

    See Compiling systemInfo.dll, jmxlibid.dll, and genrandom.dll for Win32 Systems Using Microsoft Visual C++ for instructions on compiling for a Win32 system.

    For JMX API tests, the systemInfo and jmxlibid libraries must only exist in the JAR files.

  2. Compile the systemInfo and jmxlibid libraries to jck/lib/libsystemInfo.so and jck/lib/libjmxlibid.so (or *.dll for Win32 systems).
  3. Place the compiled systemInfo and jmxlibid libraries into JAR files.

    Note - Do not leave systemInfo and jmxlibid libraries in a directory that can be accessed during a test run. For example, on the Solaris platform the libraries must not be located in the directory listed in LD_LIBRARY_PATH. Only the genrandom library must be available for loading. For example, on the Solaris platform, it must be located in the directory listed in LD_LIBRARY_PATH.

  4. Remove the systemInfo and jmxlibid libraries.
Compiling libsystemInfo.so, libjmxlibid.so, and libgenrandom.so for the Solaris Platform
  • Use the command lines in Example 5-5 to compile native libraries that are a part of JMX API tests for the Solaris platform.

    Example 5-5 contains an example of compiling the systemInfo, jmxlibid, and genrandom libraries on the Solaris platform. Substitute the exact JCK and destination paths for the strings jck and jest.

Example 5-5 Compile JMX API Test Native Libraries for the Solaris Platform 
cc -G -KPIC -o dest/libsystemInfo.so \
-Ijck/src/share/lib/jni/include \
-Ijck/src/share/lib/jni/include/solaris \
jck/tests/api/javax_management/loading/data/archives/src/C \
/com_sun_management_mbeans_loading_SystemInfoUseNativeLib.c 

cc -G -KPIC -o dest/libjmxlibid.so \
-Ijck/src/share/lib/jni/include \
-Ijck/src/share/lib/jni/include/solaris \
jck/tests/api/javax_management/loading/data/archives/src/C \
/com_sun_management_mbeans_loading_GetLibIdFromNativeLib.c 

cc -G -KPIC -o dest/libgenrandom.so \
-Ijck/src/share/lib/jni/include \
-Ijck/src/share/lib/jni/include/solaris \
jck/tests/api/javax_management/loading/data/archives/src/C \
/com_sun_management_mbeans_loading_RandomGen.c
5.14.1.1 Command-Line Options for Compiling Libraries on the Solaris Platform

Table 5-25 describes the available command-line options for compiling libraries on the Solaris platform.

Table 5-25 Command-Line Options for Compiling Libraries on the Solaris Platform

Option

Description

cc

C Compiler.

-G

Generate a shared library.

-KPIC

Generate position-independent code.

-o dest/libsystemInfo.so

Specify the output file name. The destination directory dest is usually jck/lib.

-Ijck/src/share/lib/jni/include

Add the JCK include directory to the include search path.

-Ijck/src/share/lib/jni/include/solaris

Add the JCK include/solaris directory to the include search path.

jck/tests/api/javax_management/ \

loading/data/archives/src/C/ \

com_sun_management_mbeans_loading_

SystemInfoUseNativeLib.c

Input file.
Compiling libsystemInfo.so, libjmxlibid.so, and libgenrandom.so for the Solaris Platform Using Gnu C
  • Use the command lines in Example 5-6 and the Gnu C compiler to compile native libraries that are a part of the JMX API tests for the Solaris platform.

    Example 5-6 contains an example of using the Gnu C compiler to compile the systemInfo, jmxlibid, and genrandom libraries on the Solaris platform. Substitute the exact JCK and destination paths for the strings jck and dest.

Example 5-6 Compile Native Libraries for Solaris Platform Using the Gnu C Compiler 
gcc -fPIC -shared -o dest/libsystemInfo.so \
-Ijck/src/share/lib/jni/include \
-Ijck/src/share/lib/jni//include/solaris \
jck/tests/api/javax_management/loading/data/archives/src/C \
/com_sun_management_mbeans_loading_SystemInfoUseNativeLib.c 

gcc -fPIC -shared -o dest/libjmxlibid.so \
-Ijck/src/share/lib/jni/include \
-Ijck/src/share/lib/jni/include/solaris \
jck/tests/api/javax_management/loading/data/archives/src/C \
/com_sun_management_mbeans_loading_GetLibIdFromNativeLib.c 

gcc -fPIC -shared -o dest/libgenrandom.so \
-Ijck/src/share/lib/jni//include \
-Ijck/src/share/lib/jni//solaris \
jck/tests/api/javax_management/loading/data/archives/src/C \
/com_sun_management_mbeans_loading_RandomGen.c
5.14.1.2 Command-Line Options for Compiling Libraries With GNU C Compiler on the Solaris Platform

Table 5-26 describes the command-line options for using the Gnu C compiler to compile libraries on the Solaris platform.

Table 5-26 Command-Line Options for Compiling Libraries With GNU C Compiler on the Solaris Platform

Option

Description

gcc

Gnu C Compiler.

-fPIC

Emit position-independent code, suitable for dynamic linking.

-shared

Generate a shared library.

-o dest/libsystemInfo.so

Specify the output file name. The destination directory dest is usually jck/lib.

-Ijck/src/share/lib/jni/include

Add the JCK include directory to the include search path.

-Ijck/src/share/lib/jni/include/solaris

Add the JCK include/solaris directory to the include search path.

jck/tests/api/javax_management/\

loading/data/archives/src/C/\

com_sun_management_mbeans_loading_

SystemInfoUseNativeLib.c

Input file.
Compiling systemInfo.dll, jmxlibid.dll, and genrandom.dll for Win32 Systems Using Microsoft Visual C++
  • Use the command lines in Example 5-7 and the Microsoft Visual C++ (MSVC++) compiler to build the libraries for Win32 systems.

    Example 5-7 contains an example of compiling the systemInfo.dll, jmxlibid.dll, and genrandom.dll libraries on a Win32 system. Substitute the exact JCK and destination paths for the strings jck and dest.

Example 5-7 Build Win32 Libraries Using MSVC++ Compiler 
cl /DWIN32 /D_WINDOWS /Ijck\src\share\lib\jni\include \
/Ijck\src\share\lib\jni\include\win32 \
/LD /MD /Fodest\systemInfo.obj /Fedest\systemInfo.dll \
jck\tests\api\javax_management\loading\data\archives\src\C\
com_sun_management_mbeans_loading_SystemInfoUseNativeLib.c 

cl /DWIN32 /D_WINDOWS /Ijck\src\share\lib\jni\include \
/Ijck\src\share\lib\jni\include\win32 \
/LD /MD /Fodest\jmxlibid.obj /Fedest\jmxlibid.dll \
jck\tests\api\javax_management\loading\data\archives\src\C\
com_sun_management_mbeans_loading_GetLibIdFromNativeLib.c 

cl /DWIN32 /D_WINDOWS /Ijck\src\share\lib\jni\include \
/Ijck\src\share\lib\jni\include\win32 \
/LD /MD /Fodest\genrandom.obj /Fedest\genrandom.dll \
jck\tests\api\javax_management\loading\data\archives\src\C\
com_sun_management_mbeans_loading_RandomGen.c
5.14.1.3 Command-Line Options for MSVC++ Compiler

Table 5-27 contains the command-line options used to build the libraries for Win32 systems.

Table 5-27 Command-Line Options for MSVC++ Compiler

Option

Description

cl

MSVC++ compiler.

/LD /MD

Create .DLL and link it with MSVCRT.LIB (multi-threaded runtime).

/DWIN32

Define WIN32 for C preprocessor.

/D_WINDOWS

Define _WINDOWS for C preprocessor.

/Ijck\src\share\lib\jni\include

/Ijck\src\share\lib\jni\include\win32

Add the directories to the include search path.

/Fodest\systemInfo.obj

Specify the intermediate object file.

/Fedest\systemInfo.dll

Specify the output file name.

jck\tests\api\javax_management\loading\

data\archives\src\C\

com_sun_management_mbeans_loading_

SystemInfoUseNativeLib.c

Input file.

Note - To use the MSVC++ compiler, you might need to set up environment variables, such as INCLUDE, LIB, and PATH. You can use the vcvars32.bat batch file in the installed bin directory of MSVC++ to set up environment variables.

Updating res-dest/archives/MBeanUseNativeLib.jar on the Solaris Platform
  • Use the following command to update the MBeanUseNativeLib.jar file on the Solaris platform.

    jdk/bin/jar uf res-dest/archives/MBeanUseNativeLib.jar systemInfo.so

    Note - Run this command from the directory containing the libsystemInfo.so file. Before running the command, make your current directory the directory containing the libsystemInfo.so file.

Updating res-dest/archives/MBeanUseNativeLib.jar on Win32 Systems
  • Use the following command to update the MBeanUseNativeLib.jar file on Win32 Systems.

    jdk\bin\jar uf res-dest\archives\MBeanUseNativeLib.jar systemInfo.dll

    Note - Run this command from the directory containing the systemInfo.dll file. Before running the command, make your current directory the directory containing the systemInfo.dll file.

Creating res-dest/archives/OnlyLibs.jar on the Solaris Platform
  • Use the following command to create the OnlyLibs.jar file containing jmxlibid library on the Solaris platform.

    jdk/bin/jar cf res-dest/archives/OnlyLibs.jar libjmxlibid.so

    Note - Run this command from the directory containing the libjmxlibid.so file. Before running the command, make your current directory the directory containing the libjmxlibid.so file.

Creating res-dest/archives/OnlyLibs.jar on Win32 Systems
  • Use the following command to create the OnlyLibs.jar file containing jmxlibid library on the Win32 System.

    jdk\bin\jar cf res-dest\archives\OnlyLibs.jar jmxlibid.dll

    Note - Run this command from the directory containing the jmxlibid.dll file. Before running the command, make your current directory the directory containing the jmxlibid.dll file.

5.14.2 Configuration

No special requirements.

5.14.3 Execution

No special requirements.

5.14.4 Configuration Tab Name-Value Pairs

The Configuration tab name-value pairs in Table 5-28 are provided for use with the JavaTest harness test view and Test Environment dialog box when troubleshooting problems with running tests. You can view the configuration values that were used to run a specific test by choosing the Configuration tab in the Test Manager.

For a description of the test view tabs and Test Environment dialog box, see the JavaTest Harness User's Guide: Graphical User Interface included with this release or the JavaTest harness online help.

If you intend to set a configuration value in the command line to run tests, see Chapter 4 for a description of how to obtain the required question-tag names for your configuration.

Table 5-28 lists the name-values pairs displayed in the Configuration tab for the JMX API tests for advanced dynamic loading.

Table 5-28 JMX API Loading Test Configuration Tab Name-Value Pairs

Name

Value Description

platform.nativeCodeSupported

If your system supports native code, this value is true. This value signifies that the VM under test provides support for loading native code. If your system does not provide support for loading native code, this value must be false.

resource.JMXLibPath

A path to the directory containing HTML and JAR files needed to run JMX API tests. This is the directory res-dest containing the resources copied in Copying Required HTML and JAR Files.

PATH

LD_LIBRARY_PATH

The configuration file (.jti file), includes all platform-specific variables required to identify the path to the library file. Use the Configuration Editor or EditJTI to modify the .jti file to use the PATH variable for win32 test systems, and the LD_LIBRARY_PATH variable for Solaris platform test systems. If you execute your tests using the JavaTest harness agent, you must set the platform-specific system environment variables (PATH or LD_LIBRARY_PATH) before you start the agent. See jck/win32/bin/javatest for a helpful script.

5.15 JMX Remote API Tests

Table 5-29 provides the location of the JMX Remote API tests and identifies the area that is tested.

Table 5-29 JMX Remote API Test Information

Test Information

Description or Value

Area tested

JMX Remote API

Test URLs

api/javax_management/remote

5.15.1 Setup

Before you execute the tests, you must start the TNS. The TNS is located in the bin directory of the JDK release.

Starting the TNS on the Solaris Platform
  • To start the TNS on the Solaris platform, issue the following command:

    jdk/bin/tnameserv

    This starts the server listening on the default port (900). You must have root access to use this port on the Solaris platform. To use a different port, start the TNS with the -ORBInitialPort flag and a port number. For example, to use port 1234, issue the following command:

    jdk/bin/tnameserv -ORBInitialPort 1234
Starting the TNS on a Win32 System
  • To start the TNS on Win32 systems, issue the following command: 
    jdk\bin\tnameserv

    This starts the server listening on the default port (900). To use a different port, start the TNS with the -ORBInitialPort flag and a port number. For example, to use port 1234, issue the following command:

    jdk\bin\tnameserv -ORBInitialPort 1234
5.15.1.1 Setting Up a JMX Remote API Distributed Test Run

Many of the JMX Remote API tests communicate with a remote host during the test run. The remote host consists of a passive agent running on one of the Sun reference VM on a system other than the one being tested.

Note - The reference VM for the remote agent must be the same version as the VM under test.

See 5.6 Distributed Tests for setup procedures required to run distributed tests for the JMX Remote API.

5.15.2 Configuration

A number of the JMX Remote API tests use a distributed framework for testing the functionality of the JMX Remote API. See 5.6 Distributed Tests for information about configuring the JavaTest harness for using a passive agent required to run distributed tests.

5.15.3 Execution

No special requirements.

5.15.4 Configuration Tab Name-Value Pairs

The Configuration tab name-value pairs in Table 5-30 are provided for use with the JavaTest harness test view and Test Environment dialog box when troubleshooting problems with running tests. You can view the configuration values that were used to run a specific test by choosing the Configuration tab in the Test Manager.

For a description of the test view tabs and Test Environment dialog box, see the JavaTest Harness User's Guide: Graphical User Interface included with this release or the JavaTest harness online help.

If you intend to set a configuration value in the command line to run tests, see Chapter 4 for a description of how to obtain the required question-tag names for your configuration.

Table 5-30 lists the name-values pairs displayed in the Configuration tab for the JMX Remote API tests.

Table 5-30 JMX Remote API Test Configuration Tab Name-Value Pairs

Name

Value Description

ORBHost

The name of a host or machine running the TNS.

Example Configuration tab value:

discovery

ORBPort

The port number listened to by the TNS.

Example Configuration tab value:

5555

network.tcpPortRange

Some tests exercise the system's ability to request a specific port for a TCP connection. This port is determined dynamically each time the test is run. If network.tcpPortRange is 0 (zero), the test uses the OS to determine a free port that can be used for the test. This is the preferred choice, and is suitable for most operating systems. However, on some systems, the set of ports that are allocated by the OS is different from the set of ports that can be specifically requested by client code. In this case, network.tcpPortRange indicates to the test the range of ports that are available. The range is represented as port1-port2 where port1 and port2 are the bounds of the desired range, with the following limitations:

1<=port1<=port2<=65535

Example Configuration tab value:

2048-5096

5.16 JNI Implementation Tests

Table 5-31 provides the location of the Java Native Interface (JNI) implementation tests and identifies the area that is tested.

Table 5-31 JNI API Test Information

Test Information

Description or Value

Area tested

JNI

Test URLs

vm/jni

vm/instr/invokeinterface

vm/instr/invokespecial

vm/instr/invokestatic

vm/instr/invokevirtual

vm/classfmt/atr/atrnew002/atrnew00213m1

vm/classfmt/atr/atrnew002/atrnew00214m1

5.16.1 Setup

The JCK includes tests for JNI implementation. The JNI API provides a native programming interface that enables Java class files and methods that run inside a VM to interoperate with applications and libraries written in other programming languages (such as C, C++, and assembly). The JCK provides source code for the native portion of JNI implementation tests. However, the JCK does not provide native binary code of the JNI implementation tests for a particular platform.

Before running JNI implementation tests in the JavaTest harness, the following conditions must be satisfied as described in this section:

  • You must compile the jckjni C source code into a native dynamic library on the licensee's native platform (using a C or C++ compiler).

  • Your Java platform must include an implementation of the System.loadLibrary(String) method.

  • Your environment must be correctly set to load the jckjni library before tests are run ($LD_LIBRARY_PATH on Solaris platforms or %PATH% on Win32 systems).

Note - The JNI implementation tests, when calling System.loadLibrary(), might encounter a security constrained Security Manager. To pass the JNI implementation tests, such an implementation must provide a way to grant the JNI tests permission to load native libraries.

Each JNI implementation test attempts to load a small library. If the test cannot load the library, the test tries to load the entire jckjni library. These libraries are not provided with the JCK, but you can create them for development and debugging purposes.

Note - A common mistake made with JNI implementation test libraries is to attempt to use precompiled libraries for different versions of the JCK. The JNI implementation tests provide useful diagnostics for such cases. If the loaded jckjni library does not match the JCK, the JNI implementation test, vm/jni/CheckLibrary/clib001/clib00101m1/clib00101m1.html, fails with the appropriate diagnostics.

JNI implementation tests can be compiled by the ANSI C compatible compiler or by the C++ compiler. Any platform-specific usage is declared as a macro that is utilized by all of the JNI implementation tests. The JCK provides header files that define all of the macros for the reference platforms and other platforms (md stands for "machine dependent") in the following directory:

jck/src/share/lib/jni/include/platform/*_md.h

Note - The *_md.h files can be created and ported by JCK users either for or to other platforms.

To pass all JVM tests, you must build the jckjni library by compiling jck/src/share/lib/jni/jckjni.c and placing the resultant library in the jck/lib directory.

Before building the jckjni library, you must consider the following factors:

  • If a JNI implementation test library is linked dynamically, you must set up a platform-dependent system environment variable (such as LD_LIBRARY_PATH on the Solaris platform or PATH on Win32) to load the jckjni libraries.

  • In the C source for the JNI tests, the platform-specific jlong, jfloat, jdouble, and jchar type definitions are used. Actual implementations of these types might differ. As a result, all JNI implementation tests use macros instead of direct operations on jlong, jfloat, jdouble, and jchar values. For example, the list of jlong, jfloat, jdouble, and jchar macros for the Solaris platform is defined in jck/src/share/lib/jni/include/solaris/jckjlong_md.h

    If you redefine any of these macros, ensure the new header files are included when the jckjni library is built for that platform.

  • Some JNI implementation routines use the va_list type to deal with the variable number of arguments passed from native code to Java methods. Implementation of the va_list type might differ on various platforms. For that reason, specific macros for va_list usage are defined in jck/src/share/lib/jni/include/jckjni.h

    To meet local va_list implementation requirements, you might need to redefine these.

  • The jckjni.c file contains a list of #include statements that refer to the test source files in the jck/tests directory.

See Compiling jckjni.dll for Win32 Systems Using MSVC++ and Compiling libjckjni.so for the Solaris Platform for the procedures required to build the jckjni library on Win32 systems and the Solaris platform.

Compiling jckjni.dll for Win32 Systems Using MSVC++

  • Use the command lines from Example 5-8 to compile the JNI implementation tests on Win32 systems using the MSVC++ compiler.

    Substitute the exact JCK and destination paths for the strings jck and dest.

Example 5-8 MSVC++ Compile of JNI Tests for Win32 Systems 
cl /DWIN32 /D_WINDOWS /Ijck \
/Ijck\src\share\lib\jni\include \
/Ijck\src\share\lib\jni\include\win32 \
/LD /MD /Fodest\jck\jni.obj /Fedest\jckjni.dll \
jck\src\share\lib\jni\jckjni.c

5.16.2 Command-Line Options for Compiling JNI Implementation Tests on Win32 Systems

Table 5-32 describes the available command-line options for compiling JNI tests on Win32 systems.

Table 5-32 Command-Line Options for Compiling JNI Implementation Tests on Win32 Systems

Option

Description

cl

MSVC++ compiler.

/DWIN32

Define WIN32 for C preprocessor.

/D_WINDOWS

Define _WINDOWS for C preprocessor.

/Ijck

Add the JCK directory to the include search path.

/Ijck\src\share\lib\jni\include

Add jckjni.h to include search path.

/Ijck\src\share\lib\include\win32

Add jck*_md.h to include search path.

/LD /MD

Create .DLL and link it with MSVCRT.LIB (multi-threaded runtime).

/Fedest\jckjni.dll

Specify the output file name. dest represents the path of the destination directory.

/Fodest\jckjni.obj

Specify the intermediate object file name.

jck\src\share\lib\jni\jckjni.c

Input file.

Note - To use the MSVC++ compiler, you might need to set up environment variables, such as INCLUDE, LIB, and PATH. You might use file vsargs32.bat from MSVC++ to do this.

Compiling libjckjni.so for the Solaris Platform

  • Use the command lines from Example 5-9 to compile the JNI implementation tests for the Solaris platform.

    Substitute the exact JCK and destination paths for the strings jck and dest.

Example 5-9 C Compile of JNI Implementation Tests for the Solaris Platform 
cc -G -KPIC -o dest/libjckjni.so -Ijck \
-Ijck/src/share/lib/jni/include \
-Ijck/src/share/lib/jni/include/solaris \
jck/src/share/lib/jni/jckjni.c

5.16.3 Command-Line Options for Compiling JNI Implementation Tests on the Solaris Platform

Table 5-33 describes the available command-line options for compiling the JNI implementation tests on the Solaris platform.

Table 5-33 Command-Line Options for Compiling JNI Implementation Tests on the Solaris Platform

Option

Description

cc

C Compiler.

-G

Generate a shared library.

-KPIC

Generate position-independent code.

-o dest/libjckjni.so

Specify the output file name. dest represents the path of the destination directory.

-Ijck

Add the JCK directory to the include search path.

-Ijck/src/share/lib/jni/include

Add jckjni.h to the include search path.

-Ijck/src/share/lib/jni/include/solaris

Add a directory containing platform- dependent jck*_md.h files to the include search.

jck/src/share/lib/jni/jckjni.c

Input file.

Compiling libjckjni.so for the Solaris Platform Using Gnu C

  • Use the command lines from Example 5-10 to build the library by using the Gnu C compiler for the Solaris platform.

    Substitute the exact JCK and destination paths for the strings jck and dest.

Example 5-10 Gnu C Compile of JNI Tests for the Solaris Platform 
gcc -fPIC -shared -o dest/libjckjni.so -Ijck \
-Ijck/src/share/lib/jni/include \
-Ijck/src/share/lib/jni/include/solaris \
jck/src/share/lib/jni/jckjni.c

5.16.4 Command-Line Options for Compiling JNI Implementation Tests Using Gnu C

Table 5-34 describes the available Gnu C command-line options in detail.

Table 5-34 Command-Line Options for Compiling JNI Implementation Tests Using Gnu C

Option

Description

gcc

Gnu C Compiler.

-fPIC

Generate position-independent code, suitable for dynamic linking.

-shared

Generate a shared object.

-o dest/libjckjni.so

Specify the output file name. dest represents the path of the destination directory.

-Ijck

Add the JCK directory to the include search path.

-Ijck/src/share/lib/jni/include

Add jckjni.h to the include search path.

-Ijck/src/share/lib/jni/include/solaris

Add a directory containing platform-dependent jck*_md.h files to the include search path.

jck/src/share/lib/jni/jckjni.c

Input file name and location.

5.16.5 Configuration

No special requirements.

5.16.6 Execution

No special requirements.

5.16.7 Configuration Tab Name-Value Pairs

The Configuration tab name-value pairs in Table 5-35 are provided for use with the JavaTest harness test view and Test Environment dialog box when troubleshooting problems with running tests. You can view the configuration values that were used to run a specific test by choosing the Configuration tab in the Test Manager.

For a description of the test view tabs and Test Environment dialog box, see the JavaTest Harness User's Guide: Graphical User Interface included with this release or the JavaTest harness online help.

If you intend to set a configuration value in the command line to run tests, see Chapter 4 for a description of how to obtain the required question-tag names for your configuration.

Table 5-35 lists the name-values pairs displayed in the Configuration tab for the JNI implementation tests.

Table 5-35 JNI Implementation Test Configuration Tab Name-ValuePairs

Name

Value Description

platform.nativeCodeSupported

If your system supports native code, this value is true. This value signifies that the VM under test provides support for loading native code. If your system does not provide support for loading native code, this value must be false.

PATH

LD_LIBRARY_PATH

The .jti file includes all platform-specific variables required to identify the path to the library file. Use the Configuration Editor to modify the .jti file to use the PATH variable for Win32 test systems, and the LD_LIBRARY_PATH variable for Solaris platform test systems.

If you execute your tests using the JavaTest harness agent, you must set the platform-specific system environment variables (PATH or LD_LIBRARY_PATH) before you start the agent. See jck/win32/bin/javatest for a helpful script.

5.17 JVM TI Tests

The Java Virtual Machine Tool Interface (JVM TI) is a programming interface used by development and monitoring tools that provides both a way to inspect the state and to control the execution of applications running in the VM.

The JVM TI agent may be started at VM startup by specifying the native agent library name using a command line option. Implementations may also support a mechanism to start native agents some time after the VM has started (live phase) without specifying agents through Java platform command-line options. The details for how this is supported, is implementation specific. For example, a tool may use some platform specific mechanism, or implementation specific API, to attach to the running VM, and request it start a given native agent.

To test both types of starting JVM TI agents, the JCK provides JVM TI tests and JVM TI Live Phase tests.

Table 5-36 provides the location of the JVM TI tests and identifies the area that is tested.

Table 5-36 JVM TI Test Information

Test Information

Description or Value

API tested

JVM TI

Test URLs

vm/jvmti

5.17.1 Setup

The JVM TI tests and JVM TI Live Phase tests, like JNI implementation tests, use C code. It is not possible to define the compilation of either set of tests in a platform-independent way. Therefore, you must compile the JVM TI tests before running them within the JavaTest harness. Compile these files into a library named jckjvmti for the System.loadLibrary("jckjvmti") method to load them on your platform.

However, unlike JNI implementation tests, the JVM TI agent library is not loaded using System.loadLibrary() call. The JVM TI agent library is loaded by the VM and initialized during the VM startup phase. JVM TI tests and JVM TI live phase tests do System.loadLibrary() calls to bind native methods. See 5.16 JNI Implementation Tests for detailed information about JNI implementation tests.

To pass all JVM TI tests or JVM TI Live Phase tests, you must build the library jckjvmti. To build the library, compile jck/src/share/lib/jvmti/jckjvmti.c and place the resulting library in a directory that is accessible during a test run. You must specify this directory in each interview as the JVM TI library location.

The jckjvmti.c file contains a list of #include statements that refer to the test source files in the jck/tests directory.

See Compiling jckjvmti.dll for Win32 Systems for the procedure required to build the jckjvmti library on Win32 systems.

See Compiling libjckjvmti.so for the Solaris Platform and Compiling libjckjvmti.so for the Solaris Platform Using Gnu C for the procedures required to build the jckjvmti library on Solaris platforms.

If your implementation supports a mechanism to allow starting native agents some time after the VM starts (live phase) then you must also set up the test system before you can run JVM TI Live Phase tests. See 5.20.1.1 Setting up a Test System to Run Java PLIS Tests .

5.17.1.1 Setting up a Test System to Run JVM TI Live Phase Tests

The mechanism that starts JVM TI agents after the VM has started without specifying agents through Java platform command-line options is implementation specific. You must provide a wrapper class for JCK to attach to a running VM and initiate loading the native agent. The JCK uses the wrapper class to execute the JVM TI Live Phase tests. The wrapper class provided must be a subclass of the javasoft.sqe.jck.lib.attach.AttachConnector abstract class.

The JCK provides a javasoft.sqe.jck.lib.attach.JVMTIAttachConnector wrapper class to execute JVM TI Live Phase tests on JDK software.

All required Java source files of classes of the javasoft.sqe.jck.lib.attach package are located in the following directory:

jck/src/share/classes/javasoft/sqe/jck/lib/attach/

If you provide your own wrapper class, you must use either Sun's reference Java compiler or another certified compiler to compile it on one of the reference platforms.

An example compilation command for a provided wrapper class (using JDK software on the Solaris platform) is as follows:

jdk/bin/javac -d . -classpath jck/classes YourAttachConnectorClass.java

Compiled class files of javasoft.sqe.jck.lib.attach are located in a corresponding subdirectory of the jck/classes directory.

Compiling jckjvmti.dll for Win32 Systems
  • Use the command lines from Example 5-11 to compile JVM TI tests for Win32 systems using the MSVC++ compiler.

    Substitute the exact JCK and destination paths for the strings jck and dest.

Example 5-11 MSVC++ Compile of JVM TI Tests for Win32 Systems 
cl /DWIN32 /D_WINDOWS /Ijck
/Ijck\src\share\lib\jvmti\include
/Ijck\src\share\lib\jni\include
/Ijck\src\share\lib\jni\include\win32
/LD /MD /Fodest\jckjvmti.obj /Fedest\jckjvmti.dll
jck\src\share\lib\jvmti\jckjvmti.c
5.17.1.2 Command-Line Options for Compiling JVM TI Tests on Win32 Systems

Table 5-37 describes the available command-line options for compiling JVM TI tests on Win32 systems.

Table 5-37 Command-Line Options for Compiling JVM TI Tests on Win32 Systems

Option

Description

cl

MSVC++ compiler.

/DWIN32

Define WIN32 for C preprocessor.

/D_WINDOWS

Define _WINDOWS for C preprocessor.

/Ijck

Add the JCK directory to the include search path.

/Ijck\src\share\lib\jvmti\include

Add jckjvmti.h to the include search path.

/Ijck\src\share\lib\jni\include

Add jckjni.h to the include search path.

/Ijck\src\share\lib\jni\include\win32

Add jck*_md.h to the include search path.

/LD /MD

Create .DLL and link it with MSVCRT.LIB (multi-threaded runtime).

/Fedest\jckjvmti.dll

Specify the output file name. The destination directory dest is usually jck\lib.

/Fodest\jckjvmti.obj

Specify the intermediate object file name.

jck\src\share\lib\jvmti\jckjvmti.c

Input file name and location.

Note - To use the MSVC++ compiler, you might need to set up environment variables, such as INCLUDE, LIB, and PATH. You can use file vsargs32.bat from MSVC++ to do this.

Compiling libjckjvmti.so for the Solaris Platform
  • Use the command lines from Example 5-12 to compile the JVM TI tests for the Solaris platform.

    Substitute the exact JCK and destination paths for the strings jck and dest.

Example 5-12 C Compile of JVM TI Tests for the Solaris Platform 
cc -G -KPIC -o dest/libjckjvmti.so -Ijck
-Ijck/src/share/lib/jvmti/include
-Ijck/src/share/lib/jni/include
-Ijck/src/share/lib/jni/include/solaris
jck/src/share/lib/jvmti/jckjvmti.c
5.17.1.3 Command-Line Options for Compiling JVM TI Tests on the Solaris Platform

Table 5-38 describes the available command-line options for compiling JVM TI tests on the Solaris platform.

Table 5-38 Command-Line Options for Compiling JVM TI Tests on the Solaris Platform

Option

Description

cc

C compiler.

-G

Generate a shared library.

-KPIC

Generate position independent code.

-o dest/libjckjvmti.so

Specify the output file name. The destination directory dest is usually jck/lib.

-Ijck

Add the JCK directory to the include search path.

-Ijck/src/share/lib/jvmti/include

Add jckjvmti.h to the include search path.

-Ijck/src/share/lib/jni/include

Add jckjni.h to the include search path.

-Ijck/src/share/lib/jni/include/solaris

Add a directory containing platform dependent jck*_md.h files to the include search path.

jck/src/share/lib/jvmti/jckjvmti.c

Input file name and location.
Compiling libjckjvmti.so for the Solaris Platform Using Gnu C
  • Use the command lines from Example 5-13 to build the library by using the Gnu C compiler for the Solaris platform.

    Substitute the exact JCK and destination paths for the strings jck and dest.

Example 5-13 Gnu C Compile of JVM TI Tests for the Solaris Platform 
gcc -fPIC -shared -o dest/libjckjvmti.so -Ijck
-Ijck/src/share/lib/jvmti/include
-Ijck/src/share/lib/jni/include
-Ijck/src/share/lib/jni/include/solaris
jck/src/share/lib/jvmti/jckjvmti.c
5.17.1.4 Available Gnu C Command-Line Options

Table 5-39 describes the available Gnu C command-line options in detail.

Table 5-39 Available Gnu C Command-Line Options

Option

Description

gcc

Gnu C Compiler.

-fPIC

Generate position independent code, suitable for dynamic linking.

-shared

Generate a shared object.

-o dest/lib/jckjvmti.so

Specify the output file name. The destination directory dest is usually jck/lib.

-Ijck

Add the JCK directory to the include search path.

-Ijck/src/share/lib/jvmti/include

Add jckjvmti.h to the include search path.

-Ijck/src/share/lib/jni/include

Add jckjni.h to the include search path.

-Ijck/src/share/lib/jni/include/solaris

Add a directory containing platform dependent jck*_md.h files to the include search path.

jck/src/share/lib/jvmti/jckjvmti.c

Input file name and location.

5.17.2 Configuration

Additional configuration is not required if your implementation does not support a mechanism that enables starting JVM TI agents after the VM has started.

If your implementation supports a mechanism that enables starting native agents after the VM starts (live phase) then you must configure the test system before you can run JVM TI Live Phase tests. To create a configuration for running the JVM TI Live Phase tests, you must specify the wrapper class name in the interview.

5.17.3 Execution

The following sections provide information about executing JVM TI tests and JVM TI Live Phase tests.

5.17.3.1 Execution of JVM TI Tests

JVM TI tests require that the JVM TI agent library is loaded by the VM before executing a test. This library might be specified by using your platform-specific options. For example, for JDK software the library might be specified by using the VM command-line options: -agentlib or -agentpath.

Execute JVM TI command-line tests separately from other JCK tests (including JVM TI Live Phase tests). In multi-VM mode, no additional settings are required. The JavaTest harness passes JVM TI-specific options to the tested VM when there is a jvmti keyword in the test description.

However, in single-VM mode, execute only JVM TI tests when testing a JVM TI implementation. In single-VM TI mode, use the !jvmti&!jvmtilivephase keyword selection criteria to run all tests except the JVM TI JCK tests. Use jvmti&!jvmtilivephase keyword selection criteria in addition to other keywords to run only the JVM TI JCK tests but not JVM TI Live Phase JCK tests.

In single-VM mode, the JVM TI agent runs within the agent's VM. Start this VM with a JVM TI-specific command-line argument specifying the agent library (jckjvmti) to load. The argument must contain the agent option same to inform the agent of the single-VM mode. For example, for JDK this argument is the following:

-agentlib:jckjvmti=same
5.17.3.2 Execution of JVM TI Live Phase Tests

When the JVM TI Live Phase test is executed in multi-VM mode, no additional settings are required. The JavaTest harness automatically specifies the agents used in testing.

If you run the JVM TI Live Phase tests in single-VM mode, do not specify the agent library (jckjvmti) to load in command-line options.

JVM TI Live Phase tests cannot be executed in the same VM with other JCK tests (including JVM TI tests). In single-VM mode, use jvmtilivephase keyword selection criteria in addition to other keywords to run only the JVM TI Live Phase JCK tests but not JVM TI JCK tests. Use the !jvmtilivephase keyword selection criteria to run all but the JVM TI JCK Live Phase tests.

5.17.4 Configuration Tab Name-Value Pairs

The Configuration tab name-value pairs in Table 5-40 and Table 5-41 are provided for use with the JavaTest harness test views and Test Environment dialog box when troubleshooting problems with running tests. You can view the configuration values that were used to run a specific test by choosing the Configuration tab in the Test Manager.

For a description of the test view tabs and Test Environment dialog box, see the JavaTest Harness User's Guide: Graphical User Interface included with this release or the JavaTest harness online help.

If you intend to set a configuration value in the command line to run tests, see Chapter 4 for a description of how to obtain the required question-tag names for your configuration.

Table 5-40 lists the name-values pairs displayed in the Configuration tab for the JVM TI tests.

Table 5-40 JVM TI Test Configuration Tab Name-Value Pairs

Name

Value Description

platform.jvmtiSupported

If your system supports JVM TI, this value is true. This value signifies that the JVM software implementation under test provides support for JVM TI. If your system does not provide support for JVM TI, this value must be false.

PATH

LD_LIBRARY_PATH

The .jti file includes all platform-specific variables required to identify the path to the library file. Use the Configuration Editor to modify the .jti file to use the PATH variable for Win32 test systems, and the LD_LIBRARY_PATH variable for Solaris platform test systems. If you execute your tests using the JavaTest harness agent, you must set the platform-specific system environment variables (PATH or LD_LIBRARY_PATH) before you start the agent. See jck/win32/bin/javatest for a helpful script.

Table 5-41 lists the name-values pairs displayed in the Configuration tab for the JVM TI Live Phase tests.

Table 5-41 JVM TI Live Phase Test Configuration Tab Name-Value Pairs

Name

Value Description

platform.jvmtiLivePhaseSupported

String value that indicates whether a JVM TI| Live Phase implementation is provided for testing. If a JVM TI Live Phase implementation is provided, this value must be yes.

$jvmtiLivePhaseLauncherImpl

String value that indicates wrapper class name. For example, for Sun's JDK specify this value:

javasoft.sqe.jck.lib.attach.VMTIAttachConnector

PATH

LD_LIBRARY_PATH

The .jti file includes all platform-specific variables required to identify the path to the library file. Use the Configuration Editor to modify the .jti file to use the PATH variable for Win32 test systems, and the LD_LIBRARY_PATH variable for Solaris platform test systems. If you execute your tests using the JavaTest harness agent, you must set the platform-specific system environment variables (PATH or LD_LIBRARY_PATH) before you start the agent. See jck/win32/bin/javatest for a helpful script.

5.18 Java Authentication and Authorization Service Tests

Table 5-42 provides the location of the Java Authentication and Authorization Service (JAAS) tests and identifies the areas that are tested.

Table 5-42 JAAS Test Information

Test Information

Description or Value

Areas tested

javax.security

Test URLs

api/javax_security

5.18.1 Setup

No special requirements.

5.18.2 Configuration

The authorization and the login configuration policy files must be configured to run the JAAS tests. You can set them from either the JavaTest harness GUI or the command-line interface.

5.18.2.1 Authorization Policy File

If you do not set the authorization policy file in the JCK configuration file, you must use the -D switch to set it in the command line shown in the following example:

-Djava.security.auth.policy==jck/lib/jck.auth.policy

Note - The == symbol denotes absolute assignment. This causes the values in this file to override any previous settings.

5.18.2.2 Login Configuration Policy File

If you do not set the login configuration policy file in the JCKF configuration file, you must use the -D switch to set it in the command line shown in the following example:

-Djava.security.auth.login.config==jck/lib/jck.auth.login.config

Note - The == symbol denotes absolute assignment. This causes the values in this file to override any previous settings.

5.18.2.3 Specifying Policy Files Statically

Some testing environments (for example, the JavaPlug-In software) require the security files to be specified statically. You must edit the jdk/jre/lib/security/java.security file to point to the relevant security policy files. The following sections describe how to make those edits.

Java Platform Policy File

The location of policy configurations can be statically set by specifying their respective URLs in the policy.url.n property, where n is a consecutively numbered integer starting with 1.

Example:

policy.url.1=file:///jck/lib/jck.policy

If multiple configurations are specified (n >= 2), they are read and a union of the configurations is created.

If the location of the configuration is not set in jdk/jre/lib/security/java.security, and is not specified dynamically on the command line, the runtime attempts to load a default policy from the following file:

${user.home}/.java.policy
Login Configuration File

The location of login configurations can be statically set by specifying their respective URLs in the login.config.url.n property, where n is a consecutively numbered integer starting with 1.

For example:

login.config.url.1=file:///jck/lib/jck.auth.login.config

If multiple configurations are specified (n >= 2), they are read and a union of the configurations is created.

If the location of the configuration is not set in jdk/jre/lib/security/java.security, and is not specified dynamically on the command line, the Java Authorizing Authentication Service attempts to load a default configuration from the following file:

${user.home}/.java.login.config
Authorization Policy File

The location of the access control policies can be statically set by specifying their respective URLs in the auth.config.url.n property, where n is a consecutively numbered integer starting with 1.

For example:

auth.policy.url.1=file:///jck/lib/jck.auth.policy

If multiple configurations are specified (n >= 2), they are read and a union of the configurations is created.

If the location of the policy is not set in jdk/jre/lib/security/java.security, and is not specified dynamically on the command line, the JAAS access control policy defaults to an empty policy.

5.18.3 Execution

No special requirements.

5.18.4 Configuration Tab Name-Value Pairs

The Configuration tab name-value pairs in Table 5-43 are provided for use with the JavaTest harness test view and Test Environment dialog box when troubleshooting problems with running tests. You can view the configuration values that were used to run a specific test by choosing the Configuration tab in the Test Manager.

For a description of the test view tabs and Test Environment dialog box, see the JavaTest Harness User's Guide: Graphical User Interface included with this release or the JavaTest harness online help.

If you intend to set a configuration value in the command line to run tests, see Chapter 4 for a description of how to obtain the required question-tag names for your configuration.

Table 5-43 lists the name-values pairs used in the configuration and displayed in the Configuration tab that set the source of the security authentication policy file and the security authorization login file.

Table 5-43 Java Security Authorization Policy and Login Test Configuration Tab Name-Value Pairs

Name

Value Description

platform.JavaSecurityAuthPolicy

A string value that indicates whether the system under test uses a system property or other means to set the Java Security Authentication Policy.

For the VM, a system property is used to set the Java Security Authentication Policy. The string must be "java.security.auth.policy". JCK test programs can then execute instructions similar to the following:

System.setProperty\ ("java.security.auth.policy",\ "${jck_directory}/lib/\ jck.auth.policy");

Example Configuration tab value:

"java.security.auth.policy"

If the VM uses other means to source the authentication policy file (such as a URL in the $jdk/jre/lib/security/java.security file or an environment variable), the value must be "none". The JCK test programs do not execute System.setProperty(String,String) instructions when the value is "none".

Example Configuration tab value:

"none"

platform.JavaSecurityAuthLoginConfig

A string value that indicates whether the system under test uses a system property or other means to set the Java Security Authentication Login Policy.

For the VM, a system property is used to set the Java Security Authentication Login Policy. The string is:

System.setProperty \ ("java.security.auth.login.\ config", \ "${jck_directory}/lib/\ jck.auth.login.config");

Example Configuration Tab Value:

"java.security.auth.login.config"

If the VM uses other means to source the jck/lib/jck.auth.login.config authentication policy file (such as a URL in the $jdk/jre/lib/security/java.security file, an existing java.login.config file in the user home directory or an environment variable), the value must be "none". JCK test programs do not execute System.setProperty(String,String) instructions when the value is "none".

Example Configuration tab value:

"none"

5.19 Java Generic Security Service API Tests

Table 5-44 provides the location of the Java Generic Security Service API (Java GSS) tests and identifies the area that is tested.

Table 5-44 Java GSS Test Information

Test Information

Description or Value

API tested

org.ietf.jgss

Test URL

api/org_ietf/jgss

5.19.1 Setup

The Kerberos Key Distribution Center (KDC) must be set up either on the same machine as the system under test or on a remote machine networked to the system under test. See Appendix C for detailed information about obtaining Kerberos software and an example of setting up a KDC.

5.19.2 Configuration

If you do not set the KDC host name and realm values in the JCK configuration, you must set it statically in the command line.

5.19.2.1 Specifying the KDC Host Name and Realm Statically

If you did not set the KDC host name and realm values in the JCK configuration file, use the -D switch to set it in the command line (your product might use a different method):

-Djava.security.krb5.kdc=KDC-Machine-Host-Name \
-Djava.security.krb5.realm=KDC_Realm

5.19.3 Execution

No special requirements.

5.19.4 Configuration Tab Name-Value Pairs

The Configuration tab name-value pairs in Table 5-45 are provided for use with the JavaTest harness test view and Test Environment dialog box when troubleshooting problems with running tests. You can view the configuration values that were used to run a specific test by choosing the Configuration tab in the Test Manager.

For a description of the test view tabs and Test Environment dialog box, see the JavaTest Harness User's Guide: Graphical User Interface included with this release or the JavaTest harness online help.

If you intend to set a configuration value in the command line to run tests, see Chapter 4 for a description of how to obtain the required question-tag names for your configuration.

Table 5-45 lists the name-values pairs displayed in the Configuration tab for the Java GSS tests.

Table 5-45 Java GSS Test Configuration Tab Name-Value Pairs

Name

Value Description

platform.Krb5LoginModuleConfigured

This value indicates that the login module required to run Java GSS tests is configured in the JRE software.

The login module acts as a gateway to the Kerberos KDC and enables org.iet.jgss applications to log in into a KDC. See Appendix C for a description of the KDC.

The VM provides a login module, com.sun.security.auth.module.Krb5LoginModule, that can be adopted by other implementations. However, the Kerberos login module might also be bundled in a different JAR file on different platforms. Perform a query command to identify the JAR file containing the Kerberos login module.

Example query command:

%jar -tf ${JDK}/jre/lib/rt.jar | \  
grep Krb5LoginModule \  
com/sun/security/auth/module/\
Krb5LoginModule.class

If the login module is bundled with the runtime JAR file and this value is true, then the Java GSS tests are run (provided the remaining variables in this category have valid values).

Example Configuration tab value:

true

If this value is false, the Java GSS tests are not run.

platform.JavaSecurityKrb5KDC

A string value that indicates whether the system under test uses a Java technology system property or other means to set the Java Security Kerberos Version 5 Key Data Center.

Under normal circumstances, this string is "java.security.krb5.kdc".

JCK test programs can then execute instructions similar to the following:

System.setProperty \  
("java.security.krb5.kdc", \  
"KDC-Machine-Host-Name");

Example Configuration tab value:

"java.security.krb5.kdc"

If the VM uses some other means to set the KDC-Machine-Host-Name, then this value must be "none". The JCK test programs do not execute the System.setProperty(String, String) instruction when the value is "none".

Example Configuration tab value:

"none"

platform.KDCHostName

The string value of the machine name or host name of the KDC. The JCK test programs use this variable in conjunction with platform.JavaSecurityKrb5KDC to set the Java platform system property:

System.setProperty \  
("java.security.krb5.kdc", \  
"KDC-Machine-Host-Name");

Warning: The KDC machine's clock cannot vary more than 5 minutes from the test machine clock.

platform.JavaSecurityKrb5Realm

A string value that indicates whether the system under test uses a Java technology system property or other means to set the Java Security Kerberos Version 5 Realm.

Under normal circumstances, this string is "java.security.krb5.realm".

The JCK test programs can then execute instructions similar to:

System.setProperty \  
("java.security.krb5.realm", \  
"KDC_Realm");

Example Configuration tab value:

"java.security.krb5.realm"

If the VM uses some other means to set the KDC_Realm, this value must be "none".

The JCK test programs do not execute the System.setProperty(String, String) instruction if the value is "none".

Example Configuration tab value:

"none"

platform.KDCRealm

The string value of the KDC realm. The realm is a domain parameter that Kerberos uses to group users. The JCK test programs use this variable in conjunction with platform.JavaSecurityKrb5Realm to set the Java platform system property:

System.setProperty \  
("java.security.krb5.realm", \  
"KDC_Realm");

platform.KerberosServerUsername

A string value of the Kerberos principal within the realm and under KDC (the user name of a login account).

Example Configuration tab value:

"user1"

platform.KerberosServerPassword

A string value password for the Kerberos server user name.

Example Configuration tab value:

"secretPassword1"

platform.KerberosClientUsername

A string value for the client user account.

Example Configuration tab value:

"user2"

platform.KerberosClientPassword

A string value password for the client user name.

Example Configuration tab value:

"secretPassword2"

5.20 Java Programming Language Instrumentation Services Tests

The Java Programming Language Instrumentation Services (Java PLIS) implementation in the Java programming language is represented by a set of Java class files that provide services allowing Java programming language agents to instrument programs running on the Java virtual machine. The instrumentation agents are specified through Java platform command-line options (-javaagent:jarpath=options) and invoked individually when a VM is launched in the order that they appear in the command line.

Implementations might also support a mechanism to start instrumentation agents some time after the VM has started (live phase) without specifying agents through Java platform command-line options. For example, an implementation might provide a mechanism that allows a tool to attach to a running application, and initiate the loading of the instrumentation agent into the running application.

To test both types of starting instrumentation agents, the JCK provides Java PLIS tests and live phase tests.

Table 5-46 provides the location of the Java PLIS tests and identifies the areas that are tested.

Table 5-46 Java PLIS Test Information

Test Information

Description or Value

Area tested

java.lang.instrument.Instrumentation

Test URLs

api/java_lang/instrument

5.20.1 Setup

Set up the Java PLIS tests using the mechanism supported by the implementation. Several Java PLIS tests use C code to check that when automatic native method resolution fails, it can be correctly retried using supplied prefix and enable bytecode instrumentation to be applied to native methods. Because these tests use C code, it is not possible to supply a platform-independent version of the tests. Therefore, you must compile these tests before running them. The files must be compiled into a library named jckjni for loading using the method System.loadLibrary("jckjni").

When building the jckjni library, if the library is linked dynamically, you must set up a platform-dependent system environment variable such as LD_LIBRARY_PATH on the Solaris platform, or PATH on Win32 that specifies the path to the jckjni library.

See Compiling jckjni.dll for Win32 Systems Using MSVC++ and Compiling libjckjni.so for the Solaris Platform for the procedures required to build the jckjni library on Win32 systems and the Solaris platform.

5.20.1.1 Setting up a Test System to Run Java PLIS Tests

No special requirements are required if your implementation does not support any mechanism to allow starting instrumentation agents some time after the VM has started.

If your implementation supports a mechanism to allow starting agents some time after the VM has started (live phase) then you must set up the test system before you can run live phase tests. The following procedures are required for this.

5.20.1.2 Setting up a Test System to Run Java PLIS Live Phase Tests

The mechanism to start instrumentation agents after the VM has started without specifying agents through Java platform command-line options is implementation specific. You must provide a wrapper class for JCK to attach to a running VM and initiate loading the agent. The JCK uses the agent to execute the live phase tests. The wrapper class provided must be a subclass of the javasoft.sqe.jck.lib.attach.AttachConnector abstract class.

The JCK provides a wrapper class javasoft.sqe.jck.lib.attach.JPLISAttachConnector to execute live phase tests on JDK software. All required Java source files of classes of package javasoft.sqe.jck.lib.attach are located in the following directory:

jck/src/share/classes/javasoft/sqe/jck/lib/attach/

If you provide your own wrapper class, you must use either Sun's reference Java compileror another certified compiler to compile it on one of the reference platforms.

An example compilation command for a provided wrapper class (using JDK software on the Solaris platform) is as follows:

jdk/bin/javac -d . -classpath jck/classes YourAttachConnectorClass.java

Compiled class files of javasoft.sqe.jck.lib.attach are located in a corresponding subdirectory of the jck/classes directory.

5.20.2 Configuration

Additional configuration is not required if your implementation does not support a mechanism that enables starting instrumentation agents some time after the VM has started.

If your implementation supports a mechanism that enables starting instrumentation agents after the VM has started (live phase) then you must configure the test system before you can run live phase tests. To create a configuration for running the live phase tests, you must specify the wrapper class name in the interview.

5.20.3 Execution

The JCK tests for Java PLIS is represented by the following two JAR files containing Java PLIS agents classes, corresponding manifest files, and classes used by agents for testing:

  • jck/lib/agent1.jar

  • jck/lib/agent2.jar

Java PLIS agents use classes from jck/lib/javatest.jar and jck/lib/jtjck.jar. In single-VM mode, jck/lib/javatest.jar and jck/lib/jtjck.jar must be in the classpath.

The following sections describe the two Java PLIS execution models supported by JCK.

5.20.3.1 Execution of Java PLIS Tests

When the Java PLIS test is executed in multi-VM mode, no additional settings are required. The JavaTest harness automatically specifies the agents used in testing.

If you run the test in single-VM mode, specify the JAR files as Java PLIS command-line options.

Java PLIS command-line tests cannot be executed in the same VM machine with other JCK tests (including live phase tests). In single-VM mode, only execute Java PLIS tests when testing a Java PLIS implementation. In single-VM mode, use the !jplis keyword selection criteria to run all but the Java PLIS JCK command-line tests.

Only one Java PLIS test is in JCK 6b, represented by two agents contained in two JAR files. In addition to standard keyword selection criteria, use the jplis keyword selection criteria to run only the Java PLIS JCK test.

Example: If the test is executed using Sun's plug-in for Netscape on a UNIX system, specify the following option in the plug-in's control panel:

-classpath=jck/lib/javatest.jar:jck/lib/jtjck.jar

As additional options in the plugin's Control Panel, specify the following:

-javaagent:jck/lib/agent1.jar=testsuiteRootDirURL,opt1 \
-javaagent:jck/lib/agent2.jar=testsuiteRootDirURL,opt2 \

Example: In single-VM mode, if the test is executed with a stand-alone JavaTest harness agent running on a UNIX system using Sun's JDK software, specify the following code in the JavaTest harness agent command line when the Java PLIS test is executed.

java -classpath jck/lib/javatest.jar:jck/lib/jtjck.jar:jck/classes \ 
-javaagent:jck/lib/agent1.jar=testsuiteRootDirURL,opt1 \ 
-javaagent:jck/lib/agent2.jar=testsuiteRootDirURL,opt2 \
com.sun.javatest.agent.AgentMain JavaTest agent options

In the example code, the following variables and options are used:

  • testsuiteRootDirURL is a URL of the JCK test suite root directory jck/tests.

    If you run the JavaTest harness agent on the Solaris platform, testsuiteRootDirURL is file://jck/tests/. For example, on UNIX systems, /java/jck might be used in the command.

    If you run the JavaTest harness agent on the Windows OS, testsuiteRootDirURL is file:///jck/tests/.

    jck is the full / separated path to the directory where JCK is installed. For example, on Windows systems, c:/java/JCK might be used in the command.

  • opt1 and opt2 are string literals without special meaning.

5.20.3.2 Execution of Java PLIS Live Phase Test

When the Java PLIS Live Phase test is executed in multi-VM mode, no additional settings are required. The JavaTest harness automatically specifies the agents used in testing.

If you run the live phase test in single-VM mode, do not specify the instrumentation JAR files jck/lib/agent1.jar and jck/lib/agent2.jar in command-line options.

The Java PLIS Live Phase test cannot be executed in the same VM with other JCK tests (including the Java PLIS test). In single-VM mode, use the !jplislivephase keyword selection criteria to run all but the live phase tests.

Only one Java PLIS Live Phase test is in JCK 6b, represented by two agents contained in two JAR files. In addition to standard keyword selection criteria, use the jplislivephase keyword selection criteria to run only the Java PLIS JCK Live Phase tests.

Example: If the test is executed using Sun's plug-in for NetscapeTM software on a UNIX system, specify the following option in the plug-in's control panel:

-classpath=jck/lib/javatest.jar:jck/lib/jtjck.jar

5.20.4 Configuration Tab Name-Value Pairs

The following sections provide information about the Configuration tab name-value pairs for Java PLIS tests and Java PLIS Live Phase tests.

5.20.4.1 Configuration Tab Name-Value Pairs for Java PLIS Tests

The Configuration tab name-value pairs in Table 5-47 are provided for use with the JavaTest harness test view and Test Environment dialog box when troubleshooting problems with running tests. You can view the configuration values that were used to run a specific test by choosing the Configuration tab in the Test Manager.

For a description of the test view tabs and Test Environment dialog box, see the JavaTest Harness User's Guide: Graphical User Interface included with this release or the JavaTest harness online help. If you intend to set a configuration value in the command line to run tests, see Chapter 4 for a description of how to obtain the required question-tag names for your configuration. Table 5-47 lists the name-values pairs displayed in the Configuration tab for the Java PLIS tests.

Table 5-47 Java PLIS Test Configuration Tab Name-Value Pairs

Name

Value Description

PATH

LD_LIBRARY_PATH

The configuration file (.jti file), includes all platform-specific variables required to identify the path to the library file. Use the Configuration Editor or EditJTI to modify the .jti file to use the PATH variable for win32 test systems, and the LD_LIBRARY_PATH variable for Solaris platform test systems. If you execute your tests using the JavaTest harness agent, you must set the platform-specific system environment variables (PATH or LD_LIBRARY_PATH) before you start the agent. See the win32/bin/javatest in the JCK installation folder for a helpful script.
5.20.4.2 Configuration Tab Name-Value Pairs for Java PLIS Live Phase Test

The Configuration tab name-value pairs in Table 5-48 are provided for use with the JavaTest harness test view and Test Environment dialog box when troubleshooting problems with running tests. You can view the configuration values that were used to run a specific test by choosing the Configuration tab in the Test Manager.

For a description of the test view tabs and Test Environment dialog box, see the JavaTest Harness User's Guide: Graphical User Interface included with this release or the JavaTest harness online help.

If you intend to set a configuration value in the command line to run tests, see Chapter 4 for a description of how to obtain the required question-tag names for your configuration.

Table 5-48 lists the name-values pairs displayed in the Configuration tab for the Java PLIS Live Phase tests.

Table 5-48 Java PLIS Live Phase Test Configuration Tab Name-Value Pairs

Name

Value Description

platform.jplisLivePhaseSupported

String value that indicates whether a Java PLIS Live Phase implementation is provided for testing. If a Java PLIS Live Phase implementation is provided, this value must be yes.

$jplisLivePhaseLauncherImpl

String value that indicates wrapper class name. For example, for Sun's JDK software specify this value:

javasoft.sqe.jck.lib.attach.JPLISAttachConnector

PATH

LD_LIBRARY_PATH

The configuration file (.jti file), includes all platform-specific variables required to identify the path to the library file. Use the Configuration Editor or EditJTI to modify the .jti file to use the PATH variable for win32 test systems, and the LD_LIBRARY_PATH variable for Solaris platform test systems. If you execute your tests using the JavaTest harness agent, you must set the platform-specific system environment variables (PATH or LD_LIBRARY_PATH) before you start the agent. See jck/win32/bin/javatest for a helpful script.

5.21 Java Platform Scripting API Tests

Table 5-49 provides the location of the Java platform scripting API tests and identifies the area that is tested.

Table 5-49 javax.script.ScriptEngineManager Test Information

Test Information

Description or Value

API Tested

javax.script

Test URLs

api/javax_script/ScriptEngineManager

5.21.1 Setup

Before using a browser to run scripting tests, you must add the provider1.jar file located at URL-TO-JCK-ROOT/tests/api/javax_script/ScriptEngineManager/ to the archive attribute in the HTML code used to launch the agent.

See Example 5-14 for an example of the applet with the archive attribute pointing to the provider1.jar used to launch the agent.

Example 5-14 Applet Used to Launch a JavaTest Agent 
<applet
code="com.sun.javatest.agent.AgentApplet"
codebase="URL-TO-ROOT/classes"
archive="../lib/javatest.jar,
../tests/api/javax_script/ScriptEngineManager/provider1.jar"
width=600
height=600 > 
</applet>

See Appendix B for detailed information about how to use the JavaTest harness with a browser (Netscape Navigator and JavaPlug-In software) and an agent to run JCK tests.

5.21.2 Configuration

No special requirements.

5.21.3 Execution

No special requirements.

5.21.4 Configuration Tab Name-Value Pairs

None.

5.22 Java RMI Compiler Tests

Table 5-50 provides the location of the Java Remote Method Invocation (Java RMI) compiler tests and identifies the areas that are tested.

Table 5-50 Java RMI Compiler Test Information

Test Information

Description or Value

API Tested

Not applicable.

Test URLs

api/java_rmi

5.22.1 Setup

No special requirements.

5.22.2 Configuration

No special requirements.

5.22.3 Execution

No special requirements.

5.22.4 Configuration Tab Name-Value Pairs

Some Java RMI compiler tests exercise the classes produced by the Java RMI compiler in a reference Java RMI runtime. These tests are identified with both runtime and compiler keywords.

The Configuration tab name-value pairs in Table 5-51 are provided for use with the JavaTest harness test view and Test Environment dialog box when troubleshooting problems with running tests. You can view the configuration values that were used to run a specific test by choosing the Configuration tab in the Test Manager.

For a description of the test view tabs and Test Environment dialog box, see the JavaTest Harness User's Guide: Graphical User Interface included with this release or the JavaTest harness online help.

If you intend to set a configuration value in the command line to run tests, see Chapter 4 for a description of how to obtain the required question-tag names for your configuration.

Table 5-51 lists the name-values pairs displayed in the Configuration tab for the Java RMI compiler tests.

Table 5-51 Java RMI Compiler Test Configuration Tab Name-Value Pairs

Name

Value Description

network.tcpPortRange

Some Java RMI tests exercise the system's ability to request a specific port for a TCP connection. This port is determined dynamically each time the test is run.

If network.tcpPortRange is set to 0 (zero), the test uses the operating system to determine a free port that can be used for the test. This is the preferred choice and suitable for most operating systems. However, on some systems the set of ports that are allocated by the operating system are different from the set of ports that can be specifically requested by client code.

In this case, network.tcpPortRange must be set to indicate to test the range of ports that are available. The range must be represented as port1-port2 where port1 and port2 are the bounds of the desired range, with the following limitations:

1<=port1<=port2<=65535

Example Configuration tab value:

2048-5096

5.23 Java RMI Tests

Table 5-52 provides the location of the Java RMI tests and identifies the area that is tested.

Table 5-52 RMI Test Information

Test Information

Description or Value

API Tested

java.rmi and subpackages

Test URLs

api/java_rmi

5.23.1 Setup

Prior to running the Java RMI Activation tests, you must start the rmid daemon on your platform.

Note - If you cannot launch another VM, these tests pass by default.

Starting the RMI Daemon on the Solaris Platform
  • Type the following command to start the RMI daemon: 
    jdk/bin/rmid

    The default daemon runs on port 1098. To change the port, start the RMI daemon with the specific port number as an argument. For example, to use port 39741, type the following command:

    jdk/bin/rmid -port 39741

    You must start the RMI daemon so that it does not use an exec policy file. Do not confuse the exec policy file with the security policy file. To start the RMI daemon without using an exec policy file type the following command:

    jdk/bin/rmid -J-Dsun.rmi.activation.execPolicy=none

    For more information about using the RMI Daemon, see http://java.sun.com/javase/6/docs/technotes/tools/solaris/rmid.html.

Starting the RMI Daemon on Win32 Systems
  • Type the following command to start the RMI daemon: 
    jdk\bin\rmid

    The default daemon runs on port 1098. To change the port, start the RMI daemon with the specific port number as an argument. For example, to use port 39741, type the following command:

    jdk\bin\rmid -port 39741

    You must start the RMI daemon so that it does not use an exec policy file. Do not confuse the exec policy file with the security policy file. To start the RMI daemon without using an exec policy file, type the following command:

    jdk\bin\rmid -J-Dsun.rmi.activation.execPolicy=none

    For more information about using the RMI Daemon, see http://java.sun.com/javase/6/docs/technotes/tools/windows/rmid.html.

5.23.2 Configuration

No special requirements.

5.23.3 Execution

No special requirements.

5.23.4 Configuration Tab Name-Value Pairs

The Configuration tab name-value pairs in Table 5-53 are provided for use with the JavaTest harness test view and Test Environment dialog box when troubleshooting problems with running tests. You can view the configuration values that were used to run a specific test by choosing the Configuration tab in the Test Manager

For a description of the test view tabs and Test Environment dialog box, see the JavaTest Harness User's Guide: Graphical User Interface included with this release or the JavaTest harness online help.

If you intend to set a configuration value in the command line to run tests, see Chapter 4 for a description of how to obtain the required question-tag names for your configuration.

Table 5-53 lists the name-values pairs displayed in the Configuration tab for the RMI tests.

Table 5-53 Java RMI Test Configuration Tab Name-Value Pairs

Name

Value Description

network.tcpPortRange

Some tests exercise the system's ability to request a specific port for a TCP connection. This port is determined dynamically each time the test is run.

If network.tcpPortRange is 0 (zero), the test uses the OS to determine a free port that can be used for the test.

This is the preferred choice, and is suitable for most operating systems. However, on some systems the set of ports that is allocated by the OS is different from the set of ports that can be specifically requested by client code.

>In this case, the values of network.tcpPortRange indicate to the test the range of ports that are available. The range is represented as port1-port2 where port1 and port2 are the bounds of the desired range with the following limitations:

1<=port1<=port2<=65535

Example Configuration tab value:

2048-5096

5.24 Java XML Digital Signature Tests

The JCK includes tests for Java XML Digital Signature API Specification (XMLDSig). XMLDSig is a standard Java platform API for generating and validating XML Signatures.

Table 5-54 provides the location of the XMLDSig tests and identifies the areas that are tested.

Table 5-54 XMLDSig Test Information

Test Information

Description or Value

API Tested

XMLDSig

Test URLs

api/javax_xml/crypto

api/javax_xml/crypto/dom

api/javax_xml/crypto/dsig

api/javax_xml/crypto/dsig/dom

api/javax_xml/crypto/dsig/keyinfo

api/javax_xml/crypto/dsig/spec

5.24.1 Setup

No special setup should be required.

5.24.2 Configuration

No special requirements.

5.24.3 Execution

A Java SE technology implementation must minimally support the default XMLSignatureFactory mechanism type, DOM. The XMLDSig tests are designed to find and test all XMLSignatureFactorys in your registered providers. The required DOM XMLSignatureFactory is tested along with any other XMLSignatureFactory that is present. If a DOM based XMLSignatureFactory is not found, many of the XMLDSig tests will fail.

If the tests do not find your default DOM XMLSignatureFactory, verify that it is properly registered. See 5.24.3.1 Register Your XMLSignatureFactory Provider for a description of how to register the required DOM XMLSignatureFactory.

5.24.3.1 Register Your XMLSignatureFactory Provider

If your XMLSignatureFactory provider is not registered, you can register the XMLSignatureFactory statically or dynamically.

Statically Registering Your XMLSignatureFactory Provider

You can statically register your XMLSignatureFactory provider by editing the security.provider property in the java.security file located in the lib/security directory of the JDK software. The security.provider property set in java.security has the following form:

security.provider.n=masterClassName

This property declares a security provider and specifies a preference order, n. When a specific provider is not requested, the preference order sets the order in which providers are searched for requested algorithms. The preference order is 1-based (in which 1 is the most preferred, followed by 2, and continuing through the remaining numbered sequence).

The masterClassName must specify the provider's master class. The provider's documentation must specify its master class. This class is always a subclass of the java.security.Provider class.

For example, if the master class is COM.acme.provider.Acme and you want to configure Acme as your third preferred provider, add the following line to the java.security file:

security.provider.3=COM.acme.provider.Acme
Dynamically Registering Your XMLSignatureFactory Provider

To register your XMLSignatureFactory provider dynamically, call either the addProvider or the insertProviderAt method in the java.security.Security class.

Dynamic registration is not persistent and can only be accomplished by trusted programs.

5.24.4 Configuration Tab Name-Value Pairs

None.

5.25 Network Tests

Table 5-55 provides the location of the network tests and identifies the area that is tested.

Table 5-55 Network Test Information

Test Information

Description or Value

API Tested

java.net

javax.net

Test URLs

api/java_net

api/javax_net

api/java_net/distributed

api/javax_net/distributed

5.25.1 Setup

Many of the network tests communicate with a remote host during the test run. The remote host consists of a passive agent running on one of the Sun reference VMs on a system other than the one being tested.

Note - The reference VM for the remote agent must be the same version as the VM under test.

See 5.6 Distributed Tests for setup procedures required to run network tests.

Note - The delivery of datagrams in the network is reliable but not guaranteed. If a test fails when a passive agent is run on a remote host in a different subnet, the cause of failure could be the result of one or more dropped datagram packets, not the test or your network configuration. You might need to reconfigure your network or run the passive agent on the same subnet to deliver the datagrams reliably so that the test passes.

5.25.2 Configuration

A number of the network tests use a distributed framework for testing the network API. Refer to 5.6 Distributed Tests for information about configuring the JavaTest harness for using a passive agent to run Distributed Tests.

5.25.3 Execution

No special requirements.

5.25.4 Configuration Tab Name-Value Pairs

The Configuration tab name-value pairs in Table 5-56 and Table 5-57 are provided for use with the JavaTest harness test view and Test Environment dialog box when troubleshooting problems with running tests. You can view the configuration values that were used to run a specific test by choosing the Configuration tab in the Test Manager.

For a description of the test view tabs and Test Environment dialog box, see the JavaTest Harness User's Guide: Graphical User Interface included with this release or the JavaTest harness online help.

If you intend to set a configuration value in the command line to run tests, see Chapter 4 for a description of how to obtain the required question-tag names for your configuration.

5.25.4.1 Basic Network Test Configuration Tab Name-Value Pairs

Table 5-56 lists the basic test configuration name-value pairs required to run the network tests.

Table 5-56 Basic Network Test Configuration Tab Name-Value Pairs

Name

Value Description

network.localHost

The host name and IP address of the machine you are using for testing. The value must be the same as the one returned by the InetAddress.getLocalHost() call.

Example Configuration tab value:

name/address

network.testHost1

The host name and IP address of some computer on your network. This must be a computer on your network with only one DNS name and only one IP address.

Example Configuration tab value:

name/address

network.testHost2

The host name and IP address of another host computer on your network.

Example Configuration tab value:

name/address

network.tcpPortRange

Some tests exercise the system's ability to request a specific port for a TCP connection. This port is determined dynamically each time the test is run.

If network.tcpPortRange is set to 0 (zero), the test uses the OS to determine a free port that can be used for the test. This is the preferred choice and is suitable for most operating systems. However, on some systems the set of ports that is allocated by the OS is different from the set of ports that can be specifically requested by client code.

In this case, network.tcpPortRange indicates to the test the range of ports that are available. The range is represented as port1-port2 where port1 and port2 are the bounds of the desired range, with the following limitations:

1<=port1<=port2<=65535

Example Configuration tab value:

2048-5096

network.udpPortRange

Some tests exercise the system's ability to request a specific port for a UDP connection. This port is determined dynamically each time the test is run. If you set network.udpPortRange to 0 (zero), the test uses the OS to determine a free port that can be used for the test.

This is the preferred choice and is suitable for most operating systems. However, on some systems the set of ports that is allocated by the OS is different from the set of ports that can be specifically requested by client code. In this case, network.udpPortRange must be set to indicate to the test the range of ports that are available. The range is represented as port1-port2 where port1 and port2 are the bounds of the desired range, with the following limitations:

1<=port1<=port2<=65535

Example Configuration tab value:

2048-5096
5.25.4.2 Network URL Test Configuration Tab Name-Value Pairs

The configuration name-value pairs in Table 5-57 represent absolute URLs that point to some existing resource accessible from your network. The content of the resource and protocol-related information (such as header fields) must not be dynamically generated, as is the case for a CGI-generated or servlet-generated resource. Because URLConnection tests are not intended to test index generation, the URL must not point to a directory.

The string must be in the following form:

protocol://host[:port]/path-to-resource

Example Configuration tab value:

protocol://web2.javasoft.som/index.html

Table 5-57 contains test configuration name-value pairs required to run URL and URLConnection tests:

Table 5-57 Network URL Test Configuration Tab Name-Value Pairs

Name

Value Description

network.httpURL

Points to an existing and accessible HTTP resource.

Example Configuration tab value:

http://web2.javasoft.com/index.html

network.ftpURL

Points to an existing and accessible FTP resource.

Example Configuration tab value:

hftp://ftp.javasoft.com/pub/README.first

network.fileURL

Points to an existing and accessible file resource on the platform under test.

Example Configuration tab value for Win32 system:

file:///c:\\autoexec.bat

Example Configuration tab value for Solaris platform:

file:///etc/passwd

network.jckHTTPProxyHost

network.jckHTTPProxyPort

The name and port number of the HTTP proxy server to be used by JCK tests if a direct connection is not used.

Example Configuration tab value:

proxy.somewhere.com

3128

If the hosts specified in network.httpURL and network.ftpURL are directly accessible, then both proxy parameters must be NONE.

If you use an HTTP proxy server for HTTP and FTP connections, these configuration values must be the name and port number of your HTTP proxy server. Your runtime implementation must use the same proxy host.

5.26 Out-of-Memory Tests

Table 5-58 provides the location of the out-of-memory tests and identifies the area that is tested.

Table 5-58 Out-of-Memory Test Information

Test Information

Description or Value

API Tested

Virtual Machine

Test URLs

lang/EXCP/excp006/excp00601

lang/EXEC/exec010/exec01001

lang/EXEC/exec010/exec01002

lang/EXEC/exec010/exec01003

lang/EXPR/expr056/expr05601

lang/EXPR/expr064/expr06401

lang/EXPR/expr070/expr07001

lang/EXPR/expr141/expr14101

JCK includes several tests that check that OutOfMemoryError is thrown.

5.26.1 Setup

No special requirements.

5.26.2 Configuration

No special requirements.

5.26.3 Execution

No special requirements.

5.26.4 Configuration Tab Name-Value Pairs

The Configuration tab name-value pairs in Table 5-59 are provided for use with the JavaTest harness test view and Test Environment dialog box when troubleshooting problems with running tests. You can view the configuration values that were used to run a specific test by choosing the Configuration tab in the Test Manager.

For a description of the test view tabs and Test Environment dialog box, see the JavaTest Harness User's Guide: Graphical User Interface included with this release or the JavaTest harness online help.

If you intend to set a configuration value in the command line to run tests, see Chapter 4 for a description of how to obtain the required question-tag names for your configuration.

Table 5-59 lists the name-values pairs displayed in the Configuration tab for the out-of-memory tests.

Table 5-59 Out-of-Memory Test Configuration Tab Name-Value Pairs

Name

Value Description

platform.expectOutOfMemory

The value true (the default) denotes that OutOfMemoryError can be thrown. The out-of-memory test completes successfully if OutOfMemoryError is thrown.

The value false denotes that the test does not wait for OutOfMemoryError to be thrown in order to complete successfully. For successful completion, the amount of memory specified in platform.maxMemory must be allocated.

platform.maxMemory

A positive double value with an optional letter denotes the amount of memory (in megabytes, kilobytes, or bytes) the test will attempt to allocate.The following letters are valid:

  • k or K indicate the value is specified in kilobytes

  • m or M indicate the value is specified in megabytes

The default value is 0 (zero).

The test attempts to allocate the memory of the size of platform.maxMemory. If OutOfMemoryError occurs, the test passes. Otherwise the value of platform.expectOutOfMemory is checked.

If platform.expectOutOfMemory is true, the test passes when OutOfMemoryError is thrown and fails when OutOfMemoryError is not thrown.

If platform.expectOutOfMemory is false, the test passes when the specified amount of memory is allocated.

A value of 0 (zero) denotes that there are no restrictions for memory allocation. This value is valid only when platform.expectOutOfMemory is true. The test passes if OutOfMemoryError is thrown.

5.27 Platform-Specific Values

Table 5-60 identifies the platform-specific values used in the configuration.

Table 5-60 Platform-Specific Values

Platform

Value

Microsoft Windows NT/2000/XP

SystemRoot

Microsoft Windows 98SE

windir

Microsoft Windows 98SE/NT/2000/XP

PATH

X11-based systems

DISPLAY

5.27.1 Setup

No special requirements.

5.27.2 Configuration

No special requirements.

5.27.3 Execution

No special requirements.

5.27.4 Configuration Tab Name-Value Pairs

The Configuration tab name-value pairs in Table 5-61 are provided for use with the JavaTest harness test view and Test Environment dialog box when troubleshooting problems with running tests. You can view the configuration values that were used to run a specific test by choosing the Configuration tab in the Test Manager.

For a description of the test view tabs and Test Environment dialog box, see the JavaTest Harness User's Guide: Graphical User Interface included with this release or the JavaTest harness online help.

If you intend to set a configuration value in the command line to run tests, see Chapter 4 for a description of how to obtain the required question-tag names for your configuration.

Table 5-61 lists the name-values pairs displayed in the Configuration tab for tests run on specific platforms.

Table 5-61 Platform-Specific Test Configuration Tab Name-Value Pairs

Name

Value Description

SystemRoot

windir

PATH

The Win32 variables SystemRoot, windir, and PATH must be properly set for error free test runs. Windows NT, Windows 2000, and Windows XP use the SystemRoot variable. Windows98SE and Windows ME use the windir variable. These variables are defined with the multiple VM environment execute command entries. For single VM environments, PATH must be set on the command line prior to launching the JavaTest harness. You can do this in the autoexec.bat file or manually via the command line with one of the following actions:

  • Specify the values on the command line using the -D option.

Example command line:

java -Dwindir=$windir com.sun.javatest.tool.Main

  • Change the definition in the .jti file.

DISPLAY

For AWT and Swing tests to run correctly, users on X11-based systems must explicitly define the DISPLAY value either in the Configuration Editor when creating the .jti file, or as a system property when starting the JavaTest harness.

Example command line:

java -DDISPLAY=$DISPLAY com.sun.javatest.tool.Main

5.28 Printing Tests

Table 5-62 provides the location of the printing tests and identifies the area that is tested.

Table 5-62 Printing Test Information

Test Information

Description or Value

API Tested

java.awt.print

javax.print

Javax.swing.JTable

Test URLs

api/java_awt/interactive/PrintDialogTest.html

api/java_awt/interactive/PageDialogTest.html

api/javax_print

api/javax_swing/interactive/JTablePrintTests.html

5.28.1 Setup

The printer must be brought online before the tests are run. Some printing tests require user interaction. For details about running interactive tests, see 5.10 Interactive Tests.

The printing interactive tests are located at api/javax_print/interactive/index.html.

5.28.2 Configuration

No special requirements.

5.28.3 Execution

No special requirements.

5.28.4 Configuration Tab Name-Value Pairs

The Configuration tab name-value pairs in Table 5-63 are provided for use with the JavaTest harness test view and Test Environment dialog box when troubleshooting problems with running tests. You can view the configuration values that were used to run a specific test by choosing the Configuration tab in the Test Manager.

For a description of the test view tabs and Test Environment dialog box, see the JavaTest Harness User's Guide: Graphical User included with this release or the JavaTest harness online help.

If you intend to set a configuration value in the command line to run tests, see Chapter 4 for a description of how to obtain the required question-tag names for your configuration.

Table 5-63 lists the name-values pairs displayed in the Configuration tab for the printing tests.

Table 5-63 Printing Test Configuration Tab Name-Value

Name

Value Description

platform.hasPrinter

Boolean value that indicates if a printer is connected to the system being tested. If a printer is connected to the system and is online, the value must be true.

Otherwise, the value must be false.

5.29 Schema Compiler

The schema compiler compiles test files and executes the resulting class files on a Sun reference runtime implementation. See Chapter 4 for information about running the tests of the devtools test suite. Table 5-64 provides the location of the schema compiler tests.

Table 5-64 Schema Compiler Test Information

Test Information

Description or Value

API tested

Not applicable. Tests for the API are located in the JCK runtime test suite.

Test URLs

xml_schema

5.29.1 Setup

Executing a schema compiler is implementation specific. Depending on whether you use the multi-VM or the single-VM execution mode, you must provide either a wrapper script or a wrapper class for JCK to execute a schema compiler.

5.29.1.1 Running a Schema Compiler in Multi-VM Mode

In multi-VM mode, the schema compiler is invoked as a separate process for each test requiring schema compilation. The JCK invokes the wrapper script for the schema compiler using the java.lang.Runtime.exec(String[] cmdarray, String[] envp) method, where cmdarray is the following:

command [classpath-option valueC] package-option valueP outputdir-option valueD [extra-options] schema-file

Optional parameters are enclosed in square brackets ([]).

  • command - The path to a wrapper-to-schema compiler. Specify this in the Configuration Editor.

  • classpath-option - The name of optional classpath option. Specify this either in the Configuration Editor or by using an environment variable.

  • valueC - The value of classpath-option is constructed by the JCK.

  • package-option - The package option name. Specify this in the Configuration Editor.

  • valueP - The value of package-option is constructed by the JCK.

  • outputdir-option - The output directory option name. Specify this in the Configuration Editor.

  • valueD - The value of outputdir-option is constructed by the JCK.

  • extra-options - Additional options and their values. Specify this in the Configuration Editor.

  • schema-file - The path constructed by the JCK to the schema to be compiled.

You can use the Configuration Editor to specify the following values for the envp parameter:

  • CLASSPATH environment variable - This is an alternative to the classpath option. The Configuration Editor enables you choose between these two alternatives.

  • Additional environment variables - As required.

Sample Scripts for Running the Reference Schema Compiler

The devtools compilers test suite provides two sample scripts that work for the reference schema compiler. You can use these scripts to develop scripts for other implementations:

  • solaris/bin/xjc.sh (or linux/bin/xjc.sh) - A ksh script. Used to run tests with the reference schema compiler on Solaris or Linux platforms.

    This script accepts the following options:

    • -d DIR-NAME - The path to the output directory.

    • -p PACKAGE-NAME - Package name to which generated .java classes are to belong.

    • -javac PACKAGE-NAME - (optional) Alternate path to the Java compiler used to compile generated Java sources.

      The script also requires the following environment variables to be set:

    • JAVA_HOME - The path to Sun reference runtime implementation.

    • CLASSPATH - The classpath required for TCK tests.

  • win32/bin/xjc.bat - Windows batch script. Used to run tests with the reference schema compiler on Windows platforms. This script is similar to the solaris/bin/xjc.sh script.

5.29.1.2 Running a Schema Compiler in Single-VM Mode

In single-VM mode, all invocations of a schema compiler are made from the JavaTest agent running in the same VM. A wrapper class for the schema compiler must implement the following interface:

package com.sun.jck.lib;
public interface XjcTool {
int compile (String[] args, PrintStream out, PrintStream err)

The invocation of the compile method should start schema compilation. The JCK includes the following class that is fully compatible with Sun's reference implementation and can be used for schema compilation:

com.sun.jck.lib.Xjc

The method uses the com.sun.tools.xjc.Driver class to compile a schema into .java sources, and then uses the Java SE 6 com.sun.tool.javac.Main class to compile the .java sources into class files:

compile (String [] args, java.io.PrintStream out, java.io.PrintStream err)

Sample Class for Running the Reference Schema Compiler

The devtools test suite provides a sample wrapper class, src/share/classes/com/sun/jck/lib/Xjc.java, which works for the reference schema compiler, and can be used to develop wrapper classes for other schema compiler implementations. The class provides the following method:

public int compile(String[] args, PrintStream out, PrintStream err)

The method supports the following args:

  • -d DIR-NAME - Path to the output directory.

  • -p PACKAGE-NAME - Package name to which generated Java classes should belong.

  • extra_options - Other options to pass to reference schema compiler.

5.29.2 Configuration

In the Configuration Editor, you must choose whether or not to start a new instance of the product from a command line each time a new test is executed. See 5.29.1 Setup for detailed instructions required to provide and use either a wrapper script or a wrapper class to execute a schema compiler.

5.29.3 Execution

No special requirements.

5.29.4 Configuration Tab Name-Value Pairs

None.

5.30 Schema Generator

The schema generator generates schemas from test files and validates the resulting schemas on the Sun reference runtime implementation. Table 5-65 provides the location of the schema generator tests.

Table 5-65 Schema Generator Test Information

Test Information

Description or Value

API tested

Not applicable. Tests for the API are located in the JCK runtime test suite.

Test URLs

java2schema

5.30.1 Setup

Executing a schema generator is implementation-specific. Depending on whether you use the multi-VM or the single-VM mode, you must provide either a wrapper script or a wrapper class for JCK to execute a schema generator.

5.30.1.1 Running a Schema Generator in Multi-VM Mode

In multi-VM mode, a schema generator is invoked as a separate process for each test requiring schema generation. The JCK invokes a wrapper script for a schema generator using the java.lang.Runtime.exec(String[] cmdarray, String[] envp) method, where cmdarray consists of the following:

command [classpath-option valueC] package-option valueP outputdir-option valueD [extra-options] java-file

Optional parameters are enclosed in square brackets ([ ]).

  • command - The path to a wrapper-to-schema generator. Specify this in the Configuration Editor.

  • classpath-option - The name of the optional classpath option. Specify this either in the Configuration Editor or by using an environment variable.

  • valueC - The value of classpath_option is constructed by the TCK.

  • package-option - The package option name. Specify this in the Configuration Editor.

  • valueP - The value of package-option is constructed by the TCK.

  • outputdir_option - The output directory option name. Specify this in the Configuration Editor.

  • valueD - The value of outputdir-option is constructed by the TCK.

  • extra-options - Additional options and their values. Specify this in the Configuration Editor.

  • java_file - The path constructed by the TCK to the Java class file source to be compiled into schema.

You can use the test harness configuration editor to specify the following values for the envp parameter:

  • CLASSPATH environment variable - Alternative to the classpath option. The Configuration Editor enables you choose between these two alternatives.

  • Additional environment variables - As required.

Sample Scripts for Running the Reference Schema Generator

The devtools compilers test suite provides two sample scripts that work with the reference schema generator, and can be used to develop scripts for other schema generator implementations:

  • solaris/bin/schemagen.sh (linux/bin/xjc.sh) - A ksh script. Used to run tests with the reference schema generator on Solaris or Linux platforms.

    This script accepts the following options:

    • JAVA-HOME - The path to the Sun reference runtime implementation.

    • CLASSPATH - The classpath required for TCK tests.

  • win32/bin/schemagen.bat - Windows batch script. Used to run tests with the reference schema generator on Windows platforms. This script is similar to the solaris/bin/schemagen.sh script.

5.30.1.2 Running a Schema Generator in Single-VM Mode

In single-VM mode, all invocations of a schema generator are made from the JavaTest agent running in the same VM. A wrapper class to a schema generator must implement the following interface:

package com.sun.jck.lib;
public interface SchemaGenTool {
int generate (String[] args, PrintStream out, PrintStream err)

The invocation of the generate method should start schema generation.

The JCK includes the following class that is fully compatible with Sun's reference implementation and can be used for schema generation:

com.sun.jck.lib.SchemaGen

The following method generates xml schema from .java class file or files:

generate (String [] args, java.io.PrintStream out, java.io.PrintStream err)

Sample Class for Running the Reference Schema Generator

The devtools compilers test suite provides a sample wrapper class, src/share/classes/com/sun/jck/lib/SchemaGen.java, which works for the reference schema generator and which can be used to develop wrapper classes for other schema generator implementations. The class provides the following method:

public int generate(String[] args, PrintStream out, PrintStream err)

The method supports the following args:

  • -d DIR-NAME - Path to the output directory.

  • -p PACKAGE-NAME - Package name to which generated schema should belong.

  • extra-options - Other options to pass to reference schema generator.

5.30.2 Configuration

In the Configuration Editor, you must choose whether or not to start a new instance of the product from a command line each time a new test is executed. See 5.30.1 Setup for detailed instructions required to provide and use either a wrapper script or a wrapper class to execute a schema generator.

5.30.3 Execution

No special requirements.

5.30.4 Configuration Tab Name-Value Pairs

None.

5.31 Security Tests

Table 5-66 provides the location of the security tests and identifies the area that is tested.

Table 5-66 Security Test Information

Test Information

Description or Value

API Tested

java.security and subpackages

javax.security and subpackages

Test URLs

api/java_security

api/javax_crypto

api/javax_security

5.31.1 Setup

To run these tests correctly, the security policy files on the system being tested must be configured properly. If the security policy files are not set up correctly, an error message similar to the following might be displayed:

Exception in thread "main" java.security.AccessControlException: 
access denied (java.io.FilePermission jlog.txt write) at 
java.security.AccessControlContext.checkPermission(Compiled Code) at 
java.security.AccessController.checkPermission(Compiled Code)

Use the following sections to set up and configure the security policy files on your system:

5.31.1.1 Specifying the Security Policy File Dynamically

The security policy files can be specified dynamically on the command line when the tests are executed. To specify a security policy file with the JDK software, include the following code in the command-line arguments:

-Djava.security.policy=policy-file-name

For example, policy-file-name might be /home/user/testfile.policy.

The following default policy file is provided:

jck/lib/jck.policy

The policy file must grant java.security.AllPermission for "standard" properties that can be accessed by anyone.

The same policy file must also be used for running rmid. For example, with the JDK software:

jdk/bin/rmid -J-Djava.security.policy=policy-file-name

For information and examples on creating a policy file, see http://java.sun.com/javase/6/docs/technotes/guides/security/PolicyFiles.html.

5.31.1.2 Configuring Security Permission for JCK

To eliminate the dependency on policy files, JCK 6b security tests perform some operations dynamically. For example, some test permissions are set to different protection domains and classes. Using these permissions, the tests can dynamically verify the compatibility of the security model and classes in your product with respect to the Java SE platform security architecture. The tests expect that the permissions in Table 5-67 are set.

Table 5-67 Security Permission for JCK

Permission

Type

createClassLoader

java.lang.RuntimePermission

Policy.getPolicy

java.security.SecurityPermission

Policy.setPolicy

java.security.SecurityPermission

Example 5-15 contains a default set of properties in the reference JDK software policy file format.

Example 5-15 Permissions Set in the Reference JDK Software Policy File 
grant {
permission java.lang.RuntimePermission "createClassLoader";
permission java.security.SecurityPermission "java.getPolicy";
permission java.security.SecurityPermission "java.setPolicy";
}

Note - In some systems, policy might be hard coded and cannot be customized as described in Example 5-15. In those cases, the tests are aware of what to expect and check for the correct behavior.

If you run the tests with an agent in a single-VM environment, you should grant these permissions when you start the agent. How you grant these permissions varies depending on how you run the agent.

5.31.1.3 Specifying a Different Security Provider

The reference JDK software distributions come with their own provider of cryptography algorithms. This provider is called sun.security.provider.Sun and is specified as a security property in the file jdk/jre/lib/security/java.security. The property is called security.provider.n where n is the ordering of the providers that are installed.

Some companies ship their own security cryptography provider containing implementations of cryptography algorithms. In these cases, you must add the provider to your list of approved providers before the JCK can pick up algorithms from your provider by default. For example, in Sun's JDK software this is done statically by editing the java.security file in the jdk/jre/lib/security directory. For each provider this file should contain a statement of the following form:

security.provider.n=masterClassName

This declares a provider and specifies its preference order n. The preference order is used to search for providers of requested algorithms when a specific provider is not requested. The order is 1-based: 1 is the most preferred, followed by 2, and so on. Be sure to assign your provider as security.provider.1 to make it the most preferred. The masterClassName entry must specify the fully qualified name of the provider's master class.

For example, the list of providers in your java.security file might look like the following:

# # List of providers and their preference orders: # 
security.provider.1=your-provider's-qualified-pathname 
security.provider.2=sun.security.provider.Sun

When the tests are run, the correct provider is verified for compatibility.

For information about implementing a provider, see How To Implement a Provider for the Java Cryptography Architecture at http://java.sun.com/javase/6/docs/technotes/guides/security/crypto/provider.html.

Note - Your system might utilize some other method to provide this configuration information or require other configuration files (such as library files) to be modified.

5.31.2 Configuration

Special configuration steps required to run the security tests are included in 5.31.1 Setup.

5.31.3 Execution

No special requirements.

5.31.4 Configuration Tab Name-Value Pairs

None.

5.32 Sound Tests

Table 5-68 provides the location of the tests that test the Java platform sound APIs and identifies the area that is tested.

Table 5-68 Sound Test Information

Test Information

Description or Value

API Tested

javax.sound

Test URLs

api/javax_sound

api/javax_sound/interactive

5.32.1 Setup

Some sound tests require user interaction. For details about running interactive tests, see 5.10 Interactive Tests.

The sound interactive tests are located at api/javax_sound/interactive/index.html.

5.32.2 Configuration

No special requirements.

5.32.3 Execution

No special requirements.

5.32.4 Configuration Tab Name-Value Pairs

The Configuration tab name-value pairs in Table 5-69 are provided for use with the JavaTest harness test view and Test Environment dialog box when troubleshooting problems with running tests. You can view the configuration values that were used to run a specific test by choosing the Configuration tab in the Test Manager.

For a description of the test view tabs and Test Environment dialog box, see the JavaTest Harness User's Guide: Graphical User Interface included with this release or the JavaTest harness online help.

If you intend to set a configuration value in the command line to run tests, see Chapter 4 for a description of how to obtain the required question-tag names for your configuration.

Table 5-69 lists the name-values pairs displayed in the Configuration tab for the sound tests.

Table 5-69 Sound Test Configuration Tab Name-Value Pairs

Name

Value Description

platform.canPlaySound

A boolean value that specifies if system sound resources are available for tests to use for playing sound.

Example Configuration tab value:

false

Note - If set to true some platforms, such as Solaris, require that the JavaTest harness or agent are run locally or remotely (for headless platforms) with appropriate permissions to access sound system resources.

platform.canRecordSound

A boolean value that specifies if system sound resources are available for tests to use for playing sound.

Example Configuration tab value:

false

platform.soundURL

The URL to a sound file available to the system. This URL is used by various sound tests for playback and conversion testing. The URL must be a sound file (wav, au, snd) that your system is capable of playing.

Example Configuration tab value:

file:///jck/tests/api/javax_sound/sound.wav

platform.canPlayMidi

A boolean value that specifies whether the system can play MIDI-encoded sound.

Example Configuration tab value:

false

5.33 Static Initialization Tests

Table 5-70 provides the location of the Static Initialization tests and identifies the area that is tested.

Table 5-70 Static Initialization Test Information

Test Information

Description or Value

API Tested

Virtual machine

Test URL

vm, lang

5.33.1 Setup

VM tests that test static initialization might require unloading between test runs, particularly in single VM environments. It is important that these VM tests run on a fresh VM. In these cases, back-to-back test execution runs fail without unloading the classes. If you are testing in a browser, you might need to exit and restart. Each test run must be preceded by some method to ensure a clean VM if you are re-testing in a single VM environment. See Chapter 4 for more information regarding single VM environments.

5.33.2 Configuration

No special requirements.

5.33.3 Execution

No special requirements.

5.33.4 Configuration Tab Name-Value Pairs

None.

5.34 Optional Static Signature Test

Table 5-71 provides the location of the Static Signature tests and identifies the area that is tested.

Table 5-71 Static Signature Test Information

Test Information

Description or Value

API Tested

API signature

Test URLs

api/signaturetest/sigtest.basic.html

api/signaturetest/sigtest.static.html

The static signature test is a variant of the conventional signature test, but the static version does more checking than the conventional version. It is an optional test, and requires that your classes are available in a format described in the VM specification, Chapter 4, and placed in a directory tree, a ZIP archive, or a JAR file.

The signature test uses reflection to analyze your Java technology runtime classes and is limited by the capabilities of the reflection API. The static signature test reads your class files directly and performs more validity checks that can be accomplished by using reflection. For example, it checks for any extra classes (such asclasses that are not defined in sigfile) added to the tested implementation.

If your class files are organized so that they can be read by this test, run this test to further ensure that your runtime system is valid.

5.34.1 Setup

No special requirements.

5.34.2 Configuration

When you select the version of the JAX-WS technology in the Configuration Editor, make sure the selected version (JAX-WS 2.0 or JAX-WS 2.1) matches the version of JAX-WS in your implementation. If the versions do not match, the tests will not run properly.

Note - See JSR 224 on the JCP web site (http://www.jcp.org) for more information about JAX-WS specification.

5.34.3 Execution

No special requirements.

5.34.4 Configuration Tab Name-Value Pairs

The Configuration tab name-value pairs in Table 5-72 are provided for use with the JavaTest harness test view and Test Environment dialog box when troubleshooting problems with running tests. You can view the configuration values that were used to run a specific test by choosing the Configuration tab in the Test Manager.

For a description of the test view tabs and Test Environment dialog box, see the JavaTest Harness User's Guide: Graphical User Interface included with this release or the JavaTest harness online help.

If you intend to set a configuration value in the command line to run tests, see Chapter 4 for a description of how to obtain the required question-tag names for your configuration.

Table 5-72 lists the name-values pairs displayed in the Configuration tab for the static signature test.

Table 5-72 Static Signature Test Configuration Tab Name-Value Pairs

Name

Value Description

platform.staticSigTestClasspath

A list of directories and .zip or .jar files that contain the tested classes. Items in the list are separated by a system-dependent path separator. This classpath must include all class libraries that are part of the JRE software except for the classes that implement Technologies in addition to the Technology Under Test (see Chapter 2, section 2.2.2 Rules for Java SE 6 Technology Products, compatibility rule 7.a)

Example Configuration tab value:

/usr/local/java/solsparc/jre/lib/\ rt.jar

platform.supportStaticSigTest

Boolean value that indicates whether the static signature test must be executed on the system being tested. The static signature test must be executed if the class files for the JRE software are delivered in a directory hierarchy, or in a ZIP or JAR file. If the class files for the JRE are delivered in a directory hierarchy, or in a ZIP or JAR file, this value must be true.

Otherwise, it must be false.

5.35 VM Tests

Java SE platform virtual machines use two strategies of class verification, a default of typechecking and a fallback mode of type inference. Typechecking is a new strategy of class verification used by Java SE platform. Verifying classes with typechecking is based on the class format extensions implemented for class files whose version number is 50.0 or greater. Class files whose version number is 50.0 or greater must be verified by typechecking.

Previous versions of the VM used type inference to verify class files. To enable backwards compatibility, the Java SE platform only allows support for a type inference fallback mode if the class file version number is 50.0. When the fallback mode is enabled, type inference is used to verify classes if typechecking fails. If the product VM supports the type inference fallback mode, class verification with both typechecking and type inference must be complaint with the specification.

Table 5-73 provides the location of the VM tests and identifies the area that is tested.

Table 5-73 VM Test Information

Test Information

Description or Value

API Tested

VM

Test URLs

vm

5.35.1 Setup

No special requirements.

5.35.2 Configuration

No special requirements.

5.35.3 Execution

When a tested VM supports the fallback mode, you must run the JCK at least twice. In one test run, each interview and the tested VM must be configured so that the fallback mode is activated. In the second test run, each interview and the tested VM must be configured so that the fallback mode is either not activated or available in the test run.

To enable fallback mode in Sun's reference implementation, provide the -XX:+FailOverToOldVerifier option when answering the Other Options question of each interview.

To disable fallback mode in Sun's reference implementation, provide the -XX:-FailOverToOldVerifier option when answering the Other Options question of each interview.

5.35.4 Configuration Tab Name-Value Pairs

The Configuration tab name-value pairs in Table 5-74 are provided for use with the JavaTest harness test view and Test Environment dialog box when troubleshooting problems with running tests. You can view the configuration values that were used to run a specific test by choosing the Configuration tab in the Test Manager.

For a description of the test view tabs and Test Environment dialog box, see the JavaTest Harness User's Guide: Graphical User Interface included with this release or the JavaTest harness online help.

If you intend to set a configuration value in the command line to run tests, see Chapter 4 for a description of how to obtain the required question-tag names for your configuration.

Table 5-74 lists the name-values pairs displayed in the Configuration tab for the VM tests.

Table 5-74 VM Test Configuration Tab Name-Value Pairs

Name

Value Description

platform.isFallbackSupported

If your product VM performs the verification by the type inference when the typechecking fails, this value is true.

If your product VM does not perform the verification by the type inference when the typechecking fails, this value is false.
Previous Contents Index Next
Company Info Contact Terms of Use Privacy Copyright 1994-2008 Sun Microsystems, Inc.