RFR 8028141 intermittent test failure of LocalManagementTest

[Chris Hegarty]

Roger,

Thanks for the reply. I agree completely with your explanation.

I understand there are multiple efforts running to address this issue, 
so I'll leave it to yourselves to work out the details, but as far as a 
point fix, yours is good.

-Chris.

On 11/19/2013 01:09 AM, roger riggs wrote:
> 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
>>>
>>>
>