JDK-8199638 : Test plan for JDK-8194812 Extend class-data sharing to support the module path
  • Type: Sub-task
  • Component: hotspot
  • Sub-Component: runtime
  • Affected Version: 11
  • Priority: P3
  • Status: Closed
  • Resolution: Delivered
  • Submitted: 2018-03-14
  • Updated: 2018-04-23
  • Resolved: 2018-04-23
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 11
11Resolved
Description
Test inventory

1. Existing tests

    open/test/hotspot/jtreg/runtime/SharedArchiveFile
    open/test/hotspot/jtreg/runtime/appcds

    Some tests under the open/test/hotspot/jtreg/runtime/appcds/jigsaw directory and its sub-directories may require
    modifications.

2. New tests

   New tests will be added under open/test/hotspot/jtreg/runtime/appcds/modulepath.

   Regression tests: None

   Functional tests:
   1) Simple test with ���module-path and -m options in the command line
        java --module-path mod_dir -m myModule
        a) location of module is the same during dump time and run time
            dump time: the classes in the --module-path should be archived
            run time: the classes in the --module-path should be loaded from the archive
        b) locations of module are different during dump time and run time
            dump time: the classes in the --module-path should be archived
            run time: the classes in the --module-path should not be loaded from the archive
        c) location of module is the same during dump time and run time; with an non-existence path appended to the --module-path during run time
           the non-existence path will be ignored, the results are the same as in case i.

   2) Test with -cp and ���module-path and -m
        if the main class is specified such as:
        a) java -cp my.jar --module-path mod_dir -m myModule
           the Main class is expected to be found in myModule where the mod_dir contains the necessary modular jar(s) for myModule
           dump time: the Main class should be archived
           run time: the Main class should be loaded from the archive
        b) java -cp my.jar --module-path mod_dir myMainClass -m myModule
            the myMainClass will be loaded from my.jar
            dump time: the Main class should be archived from my.jar
            run time: the Main class should be loaded from the archive
        c) java -cp my.jar -���module-path mod_dir -m myModule myMainClass
            the Main class will be loaded from myModule
           (for cases b and c, the first located ���Main��� class will be used)
           dump time: the Main class should be archived from the jar in the --module-path
           run time: the Main class should be loaded from the archive

   3) Test a modular jar in -cp depends on a module in -���module-path
        java -cp my.jar -���module-path mod_dir -���add-modules myModule myMainClass
       (e.g. myMainClass is in my.jar; this is to test classes in both jar and module will be archived and the archived classes will be
        loaded during run time with AppCDS enabled)
       dump time: myMainClass and its dependent classes should be archived
       run time: myMainClass and its dependent classes should be loaded from the archive

   4) Test a regular jar in -cp depends on a module in -���module-path
        java -cp my.jar -���module-path mod_dir -���add-modules myModule -���add-exports myModule/myPkg=ALL-UNNAMED \
            myMainClass
        similar to 3 but with a regular jar file in the -cp
        (note that an unnamed module can have dependency on a named module but not the other way around)
        the results should be the same as in case 3.

   5) Test with the --upgrade-module-path, the --limit-modules, and the --patch-module options
        For each of the above option
        dump time: vm should exit with an error message
        run time: sharing will be disabled; classes will not be loaded from the archive

   6) Test with --add-modules
        Dump with the --add-modules option, e.g. java --module-path mod_dir -Xshare:dump -XX:SharedClassListFile=test.classlist --add-modules mod1,mod2
        assuming test.classlist contains the names of classes in mod1 and mod2, the classes should be archived
        Make sure the classes can be loaded from the archive during run time.

   7) Test with 2 directories specified in the --module-path. Each directory containing a modular jar.
        During run time, change the location of one of the modular jar.
        The class from the unchanged location of the modular jar should be loaded from the archive.
        The class from the changed location of the module jar should be loaded from the jar.

   8) Test if the timestamp of a modular jar has been changed after dumping the archive, run time should fail with the appropriate
       error message. The behavior should be the same as before with -cp.

   9) Test to show that JvmtiEnv::AddToBootstrapClassLoaderSearch and JvmtiEnv::AddToSystemClassLoaderSearch should disable AppCDS.
        The behavior should be the same as before with -cp.

   Stress tests: None

   JCK tests: no new tests

Test execution matrix
1. hs-tier1 through hs-tier6 via mach5

Success criteria 
1. Test pass rate - at RDP-2 level of quality 
2. Test stability - all new tests are stable 
3. No native coverage test required 
4. No measurable performance degradation
Comments
Can this subtask be closed?
23-04-2018

Test plan is approved by SQE.
06-04-2018