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

[Seán Coffey]

Your patch looks ok to me Valerie. I note that John mentions an anomaly 
with your patch - I'm thinking that may need further investigation.

regards,
Sean.

On 06/07/2020 17:33, Valerie Peng wrote:
> 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
>>>
>>>