RFR(XS): 8219714: [testbug] com/sun/jdi/RedefineNestmateAttr/TestNestmateAttr.java must pass classpath to subprocess

[David Holmes]

Hi Goetz,

On 27/02/2019 4:36 pm, Lindenmaier, Goetz wrote:
> Hi David,
> 
> Thanks for looking this closely at the problem!

I hate unexplained behaviour :)

> I updated the webrev:
> http://cr.openjdk.java.net/~goetz/wr19/8219714-fix_TestNestmateAttr/02/

Looks good!

Thanks,
David

> Best regards,
>    Goetz
> 
> 
>> -----Original Message-----
>> From: David Holmes <david.holmes at oracle.com>
>> Sent: Wednesday, February 27, 2019 12:00 AM
>> To: Lindenmaier, Goetz <goetz.lindenmaier at sap.com>; hotspot-runtime-
>> dev at openjdk.java.net
>> Subject: Re: RFR(XS): 8219714: [testbug]
>> com/sun/jdi/RedefineNestmateAttr/TestNestmateAttr.java must pass
>> classpath to subprocess
>>
>> Hi Goetz,
>>
>> On 26/02/2019 10:58 pm, David Holmes wrote:
>>> Hi Goetz,
>>>
>>> On 26/02/2019 8:28 pm, Lindenmaier, Goetz wrote:
>>>> Hi,
>>>>
>>>> please review this tiny fix making the test pass in our
>>>> test infrastructure:
>>>> http://cr.openjdk.java.net/~goetz/wr19/8219714-
>> fix_TestNestmateAttr/01/
>>>>
>>>> The "target" did not find the testlibrary classes. Now it gets the
>>>> classpath as argument:
>>>
>>> I don't understand why we do not need this when testing here - neither
>>> locally or in our test infrastructure?
>>>
>>> Can you add the content of the failing .jtr file to the bug report so
>>> that I can see how the execution environments differ please.
>>
>> Goetz gave me the info offline - thanks
>>
>> I've determined what is going wrong. If you just run the test by itself
>> it will compile the test lib classes into the .d directory. Both the
>> main class and the Target exec'd by the main class will have a classpath
>> that consists of the tests .d directory and the Asserts class is found.
>>
>> However, if you first run a test with an explicit @build for the test
>> library then the test library classes go directly under
>> "classes/test/lib", and that means they are not created in the .d
>> directory and so the test fails as reported because Target doesn't have
>> that in its classpath.
>>
>> But the more appropriate fix is not to add the full java.class.path
>> property as a -cp arg, but just the test.class.path property:
>>
>>       argList.add(0, " -cp " + System.getProperty("test.class.path"));
>>
>> Thanks,
>> David
>>
>>> Thanks,
>>> David
>>>
>>>> Exception in thread "main" java.lang.NoClassDefFoundError:
>>>> jdk/test/lib/Asserts
>>>> at Target.main(TestNestmateAttr.java:164)
>>>> Caused by: java.lang.ClassNotFoundException: jdk.test.lib.Asserts
>>>> at
>>>>
>> java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.
>> java:583)
>>>>
>>>> at
>>>>
>> java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassL
>> oaders.java:178)
>>>>
>>>> at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:521)
>>>>
>>>> Best regards,
>>>>     Goetz.
>>>>