Well, I initially tried to use the computeIfAbsent, and I really like
how the resulting code looks. But then as I checked the javadoc of the
computeIfAbsent method, it seems that the provider verification code
does not meet the criteria of short, simple requirement of the mapping
func. In addition, the verification of 3rd party provider may trigger
the verification of other providers which means updating the other
mappings of the same map which the javadoc says the mapping func *must
not* do. I don't know the internals of ConcurrentHashMap, would this
possibly lead to a deadlock? So, I just followed the existing model of
sync'ing on JceSecurity class. I didn't proceed with performance
measuring of computeIfAbsent given the above reason.
Valerie
On 5/16/2019 2:12 AM, Alan Bateman wrote:
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?
Does it need to synchronize on JceSecurity.class? I'm mostly wondering
if it can use computeIfAbsent.
-Alan
