RFR: JDK-8156584: Initialization race in sun.security.x509.AlgorithmId.get

[Martin Buchholz]

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.fan at 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 <martinrb at 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.
>