This bug was initially created as a copy of Bug #2196908 I am copying this bug because: Needs to be fixed in RHEL 9 too Description of problem: Installing java-17-openjdk-headless on two different systems or, for example, in two different containers results in distinct classes.jsa files getting generated. This is because the CDS archive is being generated by a post script action of the java-17-openjdk-headless package. Therefore, the CDS archive is unique per installation (even if it's the same NVRA being installed), not per JDK version. This breaks usages of Application Class Data Sharing which uses the dynamic dump feature. In such a scenario the base CDS archive (and its crc) is encoded in the dynamic archive and if that doesn't match at runtime AppCDS sharing fails with: An error has occurred while processing the shared archive file. Dynamic archive cannot be used: static archive header checksum verification failed. Error occurred during initialization of VM Unable to use shared archive. Version-Release number of selected component (if applicable): java-17-openjdk-headless-17.0.7.0.7-1.el8_7.x86_64 How reproducible: Always. Steps to Reproduce: 1. Install java-17-openjdk-headless of the same NVRA multiple times 2. Observe that the classes.jsa is unique per installation (e.g. by 'ls -l' or running 'sha512sum' on the file and compare timestamps/sums) Actual results: classes.jsa is unique per installation. Expected results: classes.jsa is the same across multiple installations of java-17-openjdk-headless of the *same* NVR (Name Version Release). classes.jsa is being generated during the OpenJDK build and should be unique per build. Additional Info: This breaks some AppCDS deployment scenarios on OpenShift when using ubi8/openjdk-17 images.