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

Jonathan Gibbons jonathan.gibbons at oracle.com
Wed Jun 7 16:50:53 UTC 2017


Ioi,

Your comments are noted, but there is a better update I have had in mind 
for a while, which I have avoided until now, while we stabilize JDK 9, 
and for fear of disrupting test runs. This fix will isolate the compiled 
"class path" classes for each test, in the same way that updates for 
modules have isolated the "module path" classes for each test.

-- Jon



On 6/5/17 6:25 PM, Ioi Lam wrote:
> 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
>>
>



More information about the core-libs-dev mailing list