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 <[email protected]>
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
