RFR 8181299/10, Several jdk tests fail with java.lang.NoClassDefFoundError: jdk/test/lib/process/StreamPumper
felix.yang at oracle.com
Thu Jun 1 04:49:03 UTC 2017
just noticed your change. It is indeed necessary to clarify what is
the best practice here.
On 2017/6/1 11:32, Igor Ignatyev wrote:
> Hi Felix,
> I have suggested the exact opposite change[1-3] to fix the same problem.
>  https://bugs.openjdk.java.net/browse/JDK-8181391
> -- Igor
>> On May 31, 2017, at 8:27 PM, Felix Yang <felix.yang at oracle.com
>> <mailto:felix.yang at oracle.com>> wrote:
>> 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
>>>> <mailto: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.
>>> This may be ok to get the tests running again, but explicit build
>>> 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.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  and , 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.
>>> This may be a straight forward way to identify explicit build
>>> and avoid the wildcards.
More information about the core-libs-dev