Hi Chris and Daniel,
new webrev with a few of explicit builds than wildcard.
http://cr.openjdk.java.net/~xiaofeya/8181299/webrev.01/
Thanks,
Felix
On 2017/5/31 18:20, Chris Hegarty wrote:
On 31 May 2017, at 10:42, Felix Yang <felix.y...@oracle.com> wrote:
Hi there,
please review the patch to various jdk tests to explicitly compiling test
libraries and the lib's dependencies. Though it could be a jtreg issue (I think
so), it is necessary to get the tests running firstly.
Bug:
https://bugs.openjdk.java.net/browse/JDK-8181299
Webrev:
http://cr.openjdk.java.net/~xiaofeya/8181299/webrev.00/
This may be ok to get the tests running again, but explicit build targets
would be better. The contents, and module dependencies, from classes
in the test library are subject to change, so building all classes may
require more modules than in the @modules tags in the test.
With latest webrev, no new @modules introduced by this change, though I
fixed a missing from original tests.
I prefer to keep "@build jdk.test.lib.process.*" here. Because, with
current test lib package layout, "@build jdk.test.lib.process.*" equals
with
/@build jdk.test.lib.process.OutputAnalyzer
//jdk.test.lib.process.OutputBuffer
//jdk.test.lib.process.ProcessTools
////jdk.test.lib.process.//StreamPumper//
///jdk.test.lib.process.ExitCode/ /"
It is a bit ugly and not productive, when I only use ProcessTools
directly but have to declare a bunch of @builds. That is why I think
this is not a fix but a workaround.
Thanks,
Felix
I agree with Daniel, each test should be run separately in a clean
environment, to verify that it can build the necessary dependencies.
This is actually not the case. I executed repeatedly each test works
well separately. The problem occurs when there are more and more tests
using the same test libs.
As stated in the bugs [1] and [2], if there are multi tests using a lib,
such as ProcessTools, there could be possible collision occurring on its
dependencies.
For ProcessTools, StreamPumper (ONLY) will be disappear sometimes. It
looks some dependency classes were treated by jtreg as some-how shared,
and removed unexpectedly.
[1] https://bugs.openjdk.java.net/browse/JDK-8181299
[2] https://bugs.openjdk.java.net/browse/CODETOOLS-7901986.
Thanks,
Felix
This may be a straight forward way to identify explicit build dependencies
and avoid the wildcards.
-Chris.
