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

[Felix Yang]

Hi Igor,

     just noticed your change. It is indeed necessary to clarify what is 
the best practice here.

Thanks,
Felix
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.
>
> [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 
> <http://cr.openjdk.java.net/%7Eiignatyev//8181391/webrev.00/index.html>
>
> Thanks,
> -- 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.
>>
>> http://cr.openjdk.java.net/~xiaofeya/8181299/webrev.01/ 
>> <http://cr.openjdk.java.net/%7Exiaofeya/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 
>>>> <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.
>>>>
>>>> Bug:
>>>>
>>>> https://bugs.openjdk.java.net/browse/JDK-8181299
>>>>
>>>> Webrev:
>>>>
>>>> http://cr.openjdk.java.net/~xiaofeya/8181299/webrev.00/ 
>>>> <http://cr.openjdk.java.net/%7Exiaofeya/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/4d588cd7/attachment.htm>