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

Felix Yang felix.yang at oracle.com
Thu Jun 1 03:27:41 UTC 2017

Hi Chris and Daniel,

    new webrev with a few of explicit builds than wildcard.


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 
/@build jdk.test.lib.process.OutputAnalyzer
///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.

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

> This may be a straight forward way to identify explicit build dependencies
> and avoid the wildcards.
> -Chris.

More information about the core-libs-dev mailing list