Regression Test Harness for the OpenJDK platform: jtreg
This page is primarily for developers working on the implementation of jtreg. For help on using jtreg to run OpenJDK tests, see here.
Building and testing jtreg
The primary way to build and test jtreg is using
make and the Makefiles in the make
directory. You can also use Ant to build jtreg and run a subset of
the tests using make/build.xml, but this is not
recommended for production builds.
Currently, the makefiles are just set up for use on Unix-like systems. On Windows, you can use Cygwin to provide a suitable environment for building jtreg.
For more information, see the README file in the source repository.
So you want to change jtreg ...
jtreg is not a general purpose testing harness, and primarily exists to serve the overall needs of the OpenJDK community to test the OpenJDK platform.
Many requests to change the way that jtreg runs tests can be
addressed by writing library code to be executed by jtreg, as a
"wrapper" or "envelope" for the test. This technique is already
used for many specialized testing frameworks within the various
OpenJDK test suites. It can be used to reduce the boilerplate code
in a test, to exec java with custom options, or even
exec other commands on the host system, maybe after verifying that
such commands are available.
Originally, the recommendation for writing "non-standard" tests was to use a shell script. Now, that practice is deprecated, because of the difficulty of ensuring that such tests run on all supported platforms. Instead, it is recommended to write the equivalent code in Java. Note that if the test suite is being run in agentvm or samevm mode, there is negligible overhead in compiling and executing the Java code – i.e., no extra JVMs will be started.
As a rough guideline, if you can find a way to do what you want without changing jtreg, that is generally preferable to changing jtreg.
The sort of enhancements may be considered are those that need to be handled within the jtreg infrastructure. Recent enhancements have been:
- AgentVM mode, for improved recovery after test failure.
- Support for concurrent test execution in agentvm and othervm modes.
- Integrated support for TestNG tests.
