Currently, jtreg incorrectly confuses the concept of the /directory/ in
which the test's class will be written with the /classpath/ used to
locate all of the test's classes, including any library classes. It
provides env variable TESTCLASSES and system property test.classes, and
tests use these to mean both a directory and a classpath.
jtreg will be fixed to separate the two concepts, such that
TESTCLASSES/test.classes will continue to mean the /directory/ in which
the test's class will the written, and will introduce
TESTCLASSPATH/test.class.path for the classpath used to locate all the
test's classes.
This change only affects a small number of tests, which use both
@library and TESTCLASSES. A number of serviceability tests are affected,
FAILED: sun/tools/jcmd/jcmd-big-script.sh
FAILED: sun/tools/jcmd/jcmd-f.sh
FAILED: sun/tools/jcmd/jcmd-help-help.sh
FAILED: sun/tools/jcmd/jcmd-pid.sh
FAILED: sun/tools/jinfo/Basic.sh
FAILED: sun/tools/jmap/Basic.sh
FAILED: sun/tools/jps/jps-m_2.sh
FAILED: sun/tools/jps/jps-Vvml_2.sh
FAILED: sun/tools/jstack/Basic.sh
However, all the failures are caused by issues in shared library code,
meaning that only that code needs to be updated.
The fix is to update the tests where they are using
TESTCLASSES/test.classes as a classpath.
To ease migration onto the new jtreg, it is suggested that the tests
check to see if the new variables are defined (i.e. new jtreg) and to
fall back on the old variables if they are not defined (i.e. old jtreg).
In shell terms, this can be written
${TESTCLASSPATH:-${TESTCLASSES}}
The patch can be seen here:
http://cr.openjdk.java.net/~jjg/7194035/webrev.00/
See also
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7194035
-- Jon