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

[Alan Bateman]

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.

-Alan