CDS runtime shared class path check can be unreliable for ensuring the compatibility between shared archive and the input JAR files (making sure the same set of JAR files are used at 'dump' time and runtime) in some environments. We noticed such issue in 2019 when utilizing CDS for tools in a cloud development environment. One of the main problems that we
observed was that the mtime based check was not correct and produced false results. 

In some use cases (potentially common use cases for real world applications for today's development practices), JAR files and CDS images are built and released together. As the release processes can guarantee the compatibility between the JAR file and the CDS archive for these usages, we can safely disable the corresponding path checking. That also minimizes the related runtime overhead. Additionally, new packaging scheme would also help ensure such compatibility. Hoping to bring that for discussion separately at some point.

This enhancement proposing adding a -XX:+|-ValidateSharedClassPaths option for enabling/disabling the runtime shared class paths check. We have been using that since 2019 and it has been able to satisfy common usage requirement well. We had recently planned to contribute this minor enhancement in OpenJDK some time soon. The discussion brought up by iklam@ in https://mail.openjdk.org/pipermail/hotspot-runtime-dev/2022-September/057305.html seems to be good timing.