RFR 8028141 intermittent test failure of LocalManagementTest

[roger riggs]

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.riggs at 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
>>
>>