Hi Felix, I have suggested the exact opposite change[1-3] to fix the same problem.
[1] https://bugs.openjdk.java.net/browse/JDK-8181391 [2] http://mail.openjdk.java.net/pipermail/core-libs-dev/2017-June/048012.html [3] http://cr.openjdk.java.net/~iignatyev//8181391/webrev.00/index.html Thanks, -- Igor > On May 31, 2017, at 8:27 PM, Felix Yang <felix.y...@oracle.com> wrote: > > Hi Chris and Daniel, > > new webrev with a few of explicit builds than wildcard. > > http://cr.openjdk.java.net/~xiaofeya/8181299/webrev.01/ > <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 > <https://bugs.openjdk.java.net/browse/JDK-8181299> > [2] https://bugs.openjdk.java.net/browse/CODETOOLS-7901986 > <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.
