No objection. Looks fine to me.

--Sean

On 7/19/17 7:44 AM, Alan Bateman wrote:
I'm looking at the performance of an app that initializes a lot more security classes than I expected. One part to this is the initial opening of a JAR file which ends up loading a lot of machinery that should only be needed with signed JARs.

Any objection if I change SignatureFileVerifier to initialize DisabledAlgorithmConstraints lazily? The proposed patch for jdk10/jdk10 is below.

Thanks,

-Alan


diff --git a/src/java.base/share/classes/sun/security/util/SignatureFileVerifier.java b/src/java.base/share/classes/sun/security/util/SignatureFileVerifier.java --- a/src/java.base/share/classes/sun/security/util/SignatureFileVerifier.java +++ b/src/java.base/share/classes/sun/security/util/SignatureFileVerifier.java
@@ -59,9 +59,15 @@
      /* Are we debugging ? */
      private static final Debug debug = Debug.getInstance("jar");

-    private static final DisabledAlgorithmConstraints JAR_DISABLED_CHECK =
+    /**
+ * Holder class to delay initialization of DisabledAlgorithmConstraints
+     * until needed.
+     */
+    private static class ConfigurationHolder {
+        static final DisabledAlgorithmConstraints JAR_DISABLED_CHECK =
              new DisabledAlgorithmConstraints(
DisabledAlgorithmConstraints.PROPERTY_JAR_DISABLED_ALGS);
+    }

      private ArrayList<CodeSigner[]> signerCache;

@@ -371,7 +377,7 @@
          Boolean permitted = permittedAlgs.get(algorithm);
          if (permitted == null) {
              try {
-                JAR_DISABLED_CHECK.permits(algorithm,
+ ConfigurationHolder.JAR_DISABLED_CHECK.permits(algorithm,
                          new ConstraintsParameters(timestamp));
              } catch(GeneralSecurityException e) {
                  permittedAlgs.put(algorithm, Boolean.FALSE);

Reply via email to