Hi Chris,

Here's an example from a failing test run:

     
-J-Dtest.classes=/export/jdk8-tl-test/JTwork/classes/0/sun/management/jmxremote/bootstrap
 \\
     
-J-Dtest.class.path=/export/jdk8-tl-test/JTwork/classes/0/sun/management/jmxremote/bootstrap:/export/jdk8-tl-test/JTwork/classes/0/lib/testlibrary

Note that test.classes does not include the @library path lib/testlibrary.

So if lib/testlibrary is supposed to be available to the spawned process then using test.class.path is needed.

Including @build will compile the library classes into /lib/testlibrary but that's not enough.

It happens that if the classes are not already compiled in lib/testlibrary (and there is no @build) then the files will be compiled on demand by javac into the test.classes directory. And in that case they are 'accidentally' available to the spawned process but by using @library
that does not seem to be the intention.

The test fails if the lib/testlibrary classes have been compiled by a previous test.

Yes, there are other tests using jdk.testlibrary that do not have the @build;
there maybe some tests that fail to pass the full test.class.path.
I'll recheck , but that's out of scope for the particular issue.

Thanks, Roger





On 11/18/2013 5:25 PM, Chris Hegarty wrote:
On 18 Nov 2013, at 21:59, roger riggs <roger.ri...@oracle.com> wrote:

Please review this fix to improve the reliability of the 
jmxRemote/LocalManagementTest and CustomLauncherTest. The solution may apply to 
other tests that fail with ClassNotFound.

The tests did not include the jdk.testlibrary in the classpath when it spawns a 
new process. The failure mode is dependent on the order that tests had been run.

Also note that if a test depends on classes in the jdk.testlibrary it should include 
@build <classname> to ensure they are built in the @library directory

Webrev:
http://cr.openjdk.java.net/~rriggs/webrev-localmanagement-8028141/
I've come across some of these before. The changes to the tags make sense.

About the change to the property, test.class.path, I thought test.classes was 
right. Is this different from what other tests are doing?

-Chris.

Thanks, Roger



Reply via email to