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

[Felix Yang]

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.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
[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.
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/security-dev/attachments/20170601/348e4371/attachment.htm>