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