RFR 8181299/10, Several jdk tests fail with java.lang.NoClassDefFoundError: jdk/test/lib/process/StreamPumper

[Igor Ignatyev]

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.yang at 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.yang at 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.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/security-dev/attachments/20170531/12f44537/attachment.htm>