RFR(XS): 8196124: [testbug] runtime/appcds/jigsaw/classpathtests/DummyClassesInBootClassPath.java passes despite of error
Calvin Cheung
calvin.cheung at oracle.com
Tue Jan 30 20:10:23 UTC 2018
Hi Misha,
Thanks for your review.
On 1/29/18, 8:05 PM, Mikhailo Seledtsov wrote:
> Hi Calvin,
>
> Are the explicit String match checks for output produced by
> DummyClassHelper really needed?
> If any of the checked conditions occur in the child process executing
> DummyClassHelper, it will throw an exception. This should result in
> process exiting with non-zero value. Hence, asserting that exit value
> is zero in DummyClassesInBootClassPath should be sufficient. Let me
> know if I missed something.
I'd prefer to leave the String match checks there as it will make the
test clearer on what results the test is looking for.
>
> Also, I would recommend replacing -XX:+TraceClassPaths with
> -Xlog:class+path=trace
Good point. Fixed.
Updated webrev:
http://cr.openjdk.java.net/~ccheung/8196124/webrev.01/
thanks,
Calvin
>
> Thank you,
> Misha
>
> On 1/29/18, 6:34 PM, Ioi Lam wrote:
>> Hi Calvin,
>>
>> I think this block of code can be moved to a separate method to avoid
>> duplication. Also, the test should check that the classes are loaded
>> from shared space
>>
>> for (int i = 0; i < arguments.length; i++) {
>> TestCommon.checkExec(execOutput,
>> "java.lang.NoSuchMethodException: " + arguments[i] +
>> "." +
>> METHOD_NAME);
>> }
>>
>> ->
>>
>> void checkOutput(OutputAnalyzer output, String[] classNames)
>> throws Exception {
>> for (int i = 0; i < classNames.length; i++) {
>> TestCommon.checkExec(output,
>> "java.lang.NoSuchMethodException: " + classNames[i] +
>> "." +
>> METHOD_NAME);
>> output.shouldNotContain(classNames[i] + ".class should be
>> in shared space.");
>> }
>> }
>>
>> Thanks
>>
>> - Ioi
>>
>>
>>
>>
>>
>> On 1/26/18 4:54 PM, Calvin Cheung wrote:
>>> bug: https://bugs.openjdk.java.net/browse/JDK-8196124
>>>
>>> webrev: http://cr.openjdk.java.net/~ccheung/8196124/webrev.00/
>>>
>>> Proposed changes:
>>> - add "--add-modules java.activation" during dumping and run time
>>> since the java.activation module isn't defined by default;
>>> - append the WhiteBox.jar to the -Xbootclasspath/a during dumping
>>> and create another archive for the test case which uses the WhiteBox
>>> API;
>>> - add inspection of the run time result from the test case which
>>> uses the WhiteBox API;
>>> - refactor DummyClassHelper.java; the classes in the classlist
>>> should be in the archive, the archived classes should be coming from
>>> the run time image, not from the jar file in the -cp.
>>>
>>> Tested locally on linux-x64. Will test on other platforms after
>>> system maintenance is complete.
>>>
>>> thanks,
>>> Calvin
>>
More information about the hotspot-runtime-dev
mailing list