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