For ease of use, the CDS archive contains only boot classes from the system modules, we ignore the classpath specified in the dump time command-line:

$ mkdir -p foo
$ touch foo/bar

$ rm -f tmp.jsa
$ echo java/lang/Object > classlist
$ java -Xshare:dump -XX:SharedClassListFile=classlist -XX:SharedArchiveFile=tmp.jsa -cp foo
...
$ java -Xshare:on -XX:SharedArchiveFile=tmp.jsa -version
java -Xshare:on -XX:SharedArchiveFile=tmp.jsa -Xlog:class+path=debug -version
[0.003s][info][class,path] bootstrap loader class path=/jdk/bld/dre/images/jdk/lib/modules
[0.003s][info][class,path] opened: /jdk/bld/dre/images/jdk/lib/modules
[0.012s][info][class,path] type=BOOT
[0.012s][info][class,path] Expecting BOOT path=/jdk/bld/dre/images/jdk/lib/modules
[0.012s][info][class,path] ok
[0.027s][info][class,path] checking shared classpath entry: /jdk/bld/dre/images/jdk/lib/modules
[0.027s][info][class,path] ok
java version "12-internal" 2019-03-19

^----- note that "foo" has been excluded from the dump time classpath.


However, the above will fail if the CDS archive contains only classes from the system modules, but some of these classes were loaded by the platform or app class loaders (CLDRLocaleDataMetaInfo is loaded by the platform loader):

$ rm -f tmp.jsa
$ echo sun/util/resources/cldr/provider/CLDRLocaleDataMetaInfo > classlist
$ java -Xshare:dump -XX:SharedClassListFile=classlist -XX:SharedArchiveFile=tmp.jsa -cp foo
narrow_klass_base = 0x0000000800000000, narrow_klass_shift = 3
Allocated temporary class space: 1073741824 bytes at 0x00000008c0000000
Allocated shared space: 3221225472 bytes at 0x0000000800000000
Loading classes to share ...
Loading classes to share: done.
Rewriting and linking classes ...
Rewriting and linking classes: done
Error: non-empty directory 'foo'
Hint: enable -Xlog:class+path=info to diagnose the failure
Error occurred during initialization of VM
Cannot have non-empty directory in paths

The bug is present in the JDK 12 early access build 5 (2018/8/2)