RFR(S) : 8180805 : move RandomFactory to the top level testlibrary

Alan Bateman Alan.Bateman at oracle.com
Wed May 31 08:38:30 UTC 2017

On 31/05/2017 09:05, Felix Yang wrote:

> Hi Alan
>     even with explicit compilation, I also observed failures. I'm 
> curious what is the best practice here. IMO, there could be a 
> potential jtreg bug.
One of the tests listed in JDK-8181299 is 
java/net/URLConnection/6212146/TestDriver.java. In jdk10/jdk10 the test 
description has:

@build jdk.test.lib.JDKToolFinder jdk.test.lib.process.ProcessTools Test

but the test fails intermittently with:

java.lang.NoClassDefFoundError: jdk/test/lib/process/StreamPumper
at jdk.test.lib.process.ProcessTools.getOutput(ProcessTools.java:85)
at jdk.test.lib.process.OutputAnalyzer.<init>(OutputAnalyzer.java:47)
at jdk.test.lib.process.ProcessTools.executeProcess(ProcessTools.java:397)
at jdk.test.lib.process.ProcessTools.executeProcess(ProcessTools.java:425)
at jdk.test.lib.process.ProcessTools.executeCommand(ProcessTools.java:475)
at TestDriver.main(TestDriver.java:61)

I assume changing the @build to jdk.test.lib.process.* will fix this, 
assuming all the classes needed for ProcessTools are in this package.

As to why it's intermittent then I think it's a side effect of test 
library classes being compiled by one test and then re-used by a test 
that runs sometime later in the same VM. Combine that with implicit 
compilation, varied @build usages, and concurrently should explain why 
it's intermittent. I see you've cc'ed Jon Gibbons and he is the best 
person to comment on this. Now seems a good time to get to the bottom of 
these issues, esp. with Igor changing lots of tests to drop the explicit 
compilation of test library classes.


More information about the core-libs-dev mailing list