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

Daniel D. Daugherty daniel.daugherty at oracle.com
Wed Feb 27 17:20:24 UTC 2019


On 2/26/19 5:59 PM, David Holmes wrote:
> 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 for chasing this one to ground.

Is there some way we can determine if other tests have this same problem?

Dan


>
> 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(ClassLoaders.java:178) 
>>>
>>> at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:521)
>>>
>>> Best regards,
>>>    Goetz.
>>>
>



More information about the hotspot-runtime-dev mailing list