We have often seen applications that include some class libraries that happen to be signed. The application themselves do not use code signing for security reasons. However, classes from such signed libraries are excluded from the CDS archive, leading to slower start-up time.

We should try to include such signed classes in CDS to improve start-up time.

=============

Currently, signed classes are excluded from the CDS archive in here:

https://github.com/openjdk/jdk/blob/ffa35d8cf181cfbcb54497e997dbd18a9b62b97e/src/hotspot/share/classfile/systemDictionaryShared.cpp#L281-L286

  if (k->signers() != nullptr) {
    // We cannot include signed classes in the archive because the certificates
    // used during dump time may be different than those used during
    // runtime (due to expiration, etc).
    return warn_excluded(k, "Signed JAR");
  }

This comment was based on misunderstanding of how code signing works:

- One concern was that if the certificate used to sign a class has expired, then a SecurityException may need to be thrown during java.lang.ClassLoader::loadClass(). Such behavior may not be easy to replicate inside the CDS class loading code.

- Another concern was that the certificate used to validate the class signature may be obtained from a location outside of the JAR file. I.e., is it possible to say "ignore all certificates stored in the JAR file; use these certificates instead to validate the code signatures"??

For simplification, we decided to exclude all signed classes for simplification.

==================

As shown in the attached test case (SignerTest.java), ClassLoader::loadClass() does not seem to check for certificate expiration.

Also, it might be true that code signatures are checked only with the certificates stored in the JAR file?