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

[Ioi Lam]

 From the mails I can appreciate people have wildly different opinion 
about the virtue of @build :-)

But regardless of your opinion on @build, I think the issue I identified 
in CODETOOLS-7901986 [1] is definitely a bug --  the bug is when a 
library is compiled, it incorrectly depends on classes that come from 
the test case.

Arguably, fixing this bug would make people less afraid of using @build. 
The HotSpot decided to stop using @build because unless ever single test 
is perfectly following the @build rules, there's a chance of random 
NoClassDefFoundError caused by incorrectly compiled libraries due to 
CODETOOLS-7901986.

So please fix this bug. If we want to enforce the rules for @build, that 
should be done separately. The enforcement should not be done via 
undiagnosable random failures.

Thanks

- Ioi


[1] https://bugs.openjdk.java.net/browse/CODETOOLS-7901986


On 6/5/17 3:16 PM, Jonathan Gibbons wrote:
> 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
>