RFR(S) : 8180805 : move RandomFactory to the top level testlibrary
ioi.lam at oracle.com
Tue Jun 6 01:25:40 UTC 2017
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  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
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.
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, Ioi(cc'ed) did a really great job
>> analyzing the root cause, in to words jtreg puts a part of
>> testlibrary to one path and another part to a different path.  is
>> his suggested fix for jtreg.
>> -- Igor
>>  https://bugs.openjdk.java.net/browse/CODETOOLS-7901986
>>  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>
>>> 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
>>> 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 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
>>> 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