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

Valerie Peng valerie.peng at oracle.com
Wed May 22 00:51:26 UTC 2019


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



More information about the security-dev mailing list