RFR(XS): 8219714: [testbug] com/sun/jdi/RedefineNestmateAttr/TestNestmateAttr.java must pass classpath to subprocess
Lindenmaier, Goetz
goetz.lindenmaier at sap.com
Wed Feb 27 06:36:37 UTC 2019
Hi David,
Thanks for looking this closely at the problem!
I updated the webrev:
http://cr.openjdk.java.net/~goetz/wr19/8219714-fix_TestNestmateAttr/02/
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.
> >>
More information about the hotspot-runtime-dev
mailing list