When jtreg compiles library classes, they are supposed to end up in a location within JTwork relative to that library. However, when library compilation involves compiling library classes implicitly, these end up in the calling test's JTwork area instead of in the library JTwork area. Unfortunately, this cases subsequent tests in the test run that use this library to break.

Consider a test suite with tests a/A.java and b/B.java and library class lib/Library.java that has a helper class lib/LibHelper.java. The tests have @library directives that reference lib and @build tags that reference the test class and the Library. Problems may occur depending upon the ordering of classes in the @build tags. If @build first references a test class that uses a library class, library classes that are implicitly compiled end up in the test's JTwork area instead of in the JTwork library area. See the attached zip file of a small example test suite.

If one runs "jtreg a", LibHelper.class ends up in JTwork/classes/a instead of JTwork/classes/lib. Test a will pass, but a subsequent run of test b will fail with NoClassDefFoundError on LibHelper.

However, if one removes JTwork and then runs "jtreg b", LibHelper.class ends up in JTwork/classes/lib as expected, and subsequent runs of tests a and b will succeed.