Hi, Max,
In my first prototype, I got rid of the Entries classes (for both SUN
and SunRsaSign provider) and adds the Services inside the Provider.
Later, when I saw VerificationProvider class and its dependency on the
Entries class, I have to revert back to the original approach of having
the Entries classes. I thought about putting the Entries classes into
their provider classes, however, I am not sure if any of our licensee
may remove SUN, SunRsaSign provider class which is why we have
VerificationProvider. So, I think having separate Entries classes are
probably the safest choice. As for creating a HashSet to store the
services and then putting them into provider object in individual
provider class is to work with the current API of Provider.putService()...
If you have better suggestion, I am all ears...
Thanks!
Valerie
On 12/3/2018 7:57 PM, Weijun Wang wrote:
In fact, if the only reason why those Entries classes exist is because of
VerificationProvider, can we move the content back into their Provider class as
a public static method which is still callable by VerificationProvider?
—Max
在 2018年12月4日，11:43，Weijun Wang <weijun.w...@oracle.com> 写道：
Hi Valerie
I'm looking at the put->putService changes. Before this, a single put() in
SunRsaSignEntries call adds a service but now you need to add() into a
LinkedHashSet first in SunRsaSignEntries and then putService() each back in
SunRsaSign.
I don't have a simple way to do this since Provider::putService is protected
and SunRsaSignEntries is also used in VerificationProvider, just wonder if you
have thought about this.
Thanks
Max
On Nov 22, 2018, at 2:05 AM, Valerie Peng <valerie.p...@oracle.com> wrote:
Hi,
Can someone help reviewing this fix?
Besides changing the Provider class to use ConcurrentHashMap in order to reduce
the lock contention on Provider.getService() calls, I also changed the security
providers in java.base module to register through putService(...) calls.
Performance is manually verified and mach5 run is clean.
Bug: https://bugs.openjdk.java.net/browse/JDK-7092821
Webrev: http://cr.openjdk.java.net/~valeriep/7092821/webrev.00/
Thanks,
Valerie
