RFR[15] 8248505: Unexpected NoSuchAlgorithmException when using secure random impl from BCFIPS provider

[Valerie Peng]

Hi Max,

The suggested fix is not much different than the suggested webrev.

The essential change is to call getService(...) for the returned service 
in Provider.getDefaultSecureRandomService(). The only difference here is 
using the hardcoded type "SecureRandom" vs the one returned by getType() 
call. Is this what you are referring to?

I re-write the rest to store String instead of Service as it may seem 
strange why the stored Service is not used but re-queried through 
getService(...). Also, looks cleaner to me this way.

Thanks,
Valerie
On 7/2/2020 9:05 PM, Weijun Wang wrote:
> Hi Valerie,
>
> How about the suggested fix from the bug reporter?
>
> Thanks,
> Max
>
>> On Jul 3, 2020, at 4:52 AM, Valerie Peng <valerie.peng at oracle.com> wrote:
>>
>> Hi Max and Sean,
>>
>> Can you help reviewing this fix for JDK-8248505? This is the followup fix for JDK-8246613 "Choose the default SecureRandom algo based on registration ordering" which you reviewed earlier. Based on the feedback, BCFIPS provider overrides putService/getService() calls which does not work well with the fix for JDK-8246613. Thus, I adapted to store the SecureRandom algorithm names internally and then return the result from getService(...) when Provider.getDefaultSecureRandomService() is called. Updated the regression test to include a custom provider which simulates the BCFIPS provider behavior.
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8248505
>>
>> Webrev: http://cr.openjdk.java.net/~valeriep/8248505/webrev.00/
>>
>> Thanks,
>> Valerie
>>
>>