Open NeilMadden opened 2 years ago
As long as the JDK providers are loaded by default, we could switch to not unloading these providers, instead of unloading all and re-adding via reflection.
We could also add an assertion that exactly the right set of providers is loaded; this will make error messages cleaner if something in the JDK changes and our approach no longer works. The downside is that it also makes tests brittle: do we care which providers in the JDK default setup are running, or only about the behavior of “this is the default JDK crypto setup, and it supports the options exported by the JDK”
The OpenJDK test setup code removes all security providers and then tries to re-add specific ones based on dynamic class loading. This no longer works with the latest JDKs because (a) some of the provider classes have moved/disappeared and (b) access to others is blocked by the module system.