Use a debugger to walk through a simple call to:
new SecureRandom().nextInt();
It appears as though signed jar file verification is creating a new Sun provider for each jar entry that's being verified.
In the attachments:
1.txt vs. 2.txt: There are 15 slightly different calls of the same stack.
sun.security.pkcs11.SunPKCS11.d(SunPKCS11.java:456)
calls into loadClass, which does a findClass, which brings in the URLClassLoader, which brings in JarFile, which tries to verify the Manifest via the ManifestEntryVerifier, which creates a MessageDigest, which gets a new instance of the SunProvider.
Each time we try to load a new class, we do the same thing over/over again. This seems very wasteful, and we should be grabbing the Provider if it's already been initialized.
3.txt vs. 4.txt are similar to 1/2, but just using a different new instance paths.
< sun.reflect.NativeConstructorAccessorImpl.newInstance0(NativeConstructorAccessorImpl.java)
< sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57)
---
> sun.reflect.GeneratedConstructorAccessor1.newInstance
27,28c26,28
There are 22 of these. :(