[13] RFR JDK-7107615 "scalability bloker in javax.crypto.JceSecurity"

[Valerie Peng]

Updated per Daniel's feedback on IdentityWrapper:

http://cr.openjdk.java.net/~valeriep/7107615/webrev.04/

Mach5 run is clean.

Thanks,
Valerie
On 5/21/2019 5:51 PM, Valerie Peng wrote:
> Hi Daniel,
>
> Good point, I assumed that this general purpose parameterized 
> IdentityWrapper class can easily be leveraged for similar fixes if 
> needed. As currently, only Provider type is used so it doesn't really 
> needs to use parameter type. I will update and re-test.
>
> My local build and testing runs fine. I thought my mach5 job comes 
> back ok as well. I will re-submit mach5 with the updated webrev just 
> to be safe.
>
> Regards,
> Valerie
> On 5/16/2019 1:55 AM, Daniel Fuchs wrote:
>> Hi Valerie,
>>
>> This looks good to me.
>>
>> I just wonder why IdentityWrapper has a parameter type as it
>> seems it's only used with T = Provider.
>> I mean - this is fine - and I understand why you did it this way
>> as the general purpose parameterized class is much easier to name,
>> but I wonder if you wouldn't get a "rawtype" warning at line 418 if
>> you compiled that with -Xlint.
>>
>> best regards,
>>
>> -- daniel
>>
>> On 15/05/2019 20:11, Valerie Peng wrote:
>>> I updated the webrev to switch to ConcurrentHashMap. The javadoc 
>>> spec of computeIfAbsent method cautioned that the mapping func 
>>> should be short and simple and must not attempt to update other 
>>> mappings of this map. Provider verification code does not quite fit 
>>> the above criteria for the mapping. So, I did not use 
>>> computeIfAbsent method and just made minor update to webrev.01 with 
>>> Xuelei's suggestion of re-checking the cache again inside the 
>>> synchronized block.
>>>
>>> http://cr.openjdk.java.net/~valeriep/7107615/webrev.03/
>>>
>>> Comments?
>>>
>>> Thanks,
>>> Valerie