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

[Jonathan Gibbons]

Igor, Ioi,

I have read Ioi's mail and the supposed bug fix.

While the fix may hide the problem, the root cause is still that tests 
are not providing accurate @build directives, and are relying on 
implicit compilation to compile the files. This is not the way that 
jtreg is intended to be used, and the fix merely helps hide the problem, 
albeit in a relatively elegant way.

-- Jon


On 05/31/2017 07:18 AM, Igor Ignatyev wrote:
> Hi Alan,
>
> we believe it's a jtreg bug. we have seen similar intermittent failures in hotspot testing[1], Ioi(cc'ed) did a really great job analyzing the root cause[2], in to words jtreg puts a part of testlibrary to one path and another part to a different path. [3] is his suggested fix for jtreg.
>
> -- Igor
>
> [1] https://bugs.openjdk.java.net/browse/CODETOOLS-7901986
> [2] https://bugs.openjdk.java.net/secure/attachment/70197/jtreg_random_class_not_found.txt
> [3] http://cr.openjdk.java.net/~iklam/jtreg/7901986_split_library/
>    
>> On May 31, 2017, at 1:38 AM, Alan Bateman <Alan.Bateman at oracle.com> wrote:
>>
>> 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