Hi Xuelei, I think the non-test code will work well with any set of providers, but is optimized for the default set of providers. If the user removes a provider, then the hashmap will be auto-compacted. The OidTableSize test will fail if the default providers are changed, but that actually helps maintenance efforts (if you care about optimizing startup; it's also reasonable not to care, and to delete the OidTableSize test entirely).
On Wed, May 11, 2016 at 9:33 PM, Xuelei Fan <xuelei....@oracle.com> wrote: > AlgorithmId.java > ================ > Line 582-587, about the capacity of hash map, applications may customize > Security providers and more OID numbers may get removed/added later, so > the oid number may be not a fixed hard-coded number. It may be easier > to maintain the code if using the default initial capacity of HashMap. > > Thanks, > Xuelei > > > On 5/12/2016 1:01 AM, Martin Buchholz wrote: >> Webrev updated. >> Still looking for crypto-collaborator. >> >> On Tue, May 10, 2016 at 12:43 PM, Martin Buchholz <marti...@google.com> >> wrote: >>> https://bugs.openjdk.java.net/browse/JDK-8156584 >>> http://cr.openjdk.java.net/~martin/webrevs/openjdk8/AlgorithmId-get-race/ >>> >>> I'm not a crypto engineer, so I'm hoping someone on security-dev >>> adopts this fix. But current webrev is intended to be a complete fix >>> for jdk8. >
