RFR(XS): 8196124: [testbug] runtime/appcds/jigsaw/classpathtests/DummyClassesInBootClassPath.java passes despite of error
Ioi Lam
ioi.lam at oracle.com
Tue Jan 30 02:34:32 UTC 2018
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