[14] RFR JDK-8228613 "java.security.Provider#getServices order is no longer deterministic"

[Weijun Wang]

Hi Valerie,

I prefer this fix which is totally internal and expose nothing to the public. It looks fine to me.

> On Aug 13, 2019, at 9:02 AM, Valerie Peng <valerie.peng at oracle.com> wrote:
> 
> 
> Webrev updated to use a static constant in SunEntries:
> 
> http://cr.openjdk.java.net/~valeriep/8228613/webrev.01/
> 
> Thanks~
> Valerie
> On 8/12/2019 4:22 PM, Valerie Peng wrote:
>> 
>> Sure, I considered the internal approach as well, but feel an alias of DEFAULT seems cleaner than a static constant in SunEntries class. I can go the other way if you prefer.
>> 
>> The spec didn't spell clearly as to how the default random number algorithm is determined and I think it can be provider-specific. This is a regression and we need to backport this. Hope that a new concept/CSR won't shut the door for backport?

Maybe we can do this later, and maybe you can take back the "DEFAULT" algorithm if that's the suggested way to indicate a default algorithm, or maybe it can be described somewhere inside the attributes.

Thanks,
Max


>> 
>> Valerie
>> 
>> 
>> On 8/10/2019 7:32 PM, Weijun Wang wrote:
>>> The spec for SecureRandom has:
>>> 
>>> /**
>>>   * Constructs a secure random number generator (RNG) implementing the
>>>   * default random number algorithm.
>>>   *
>>>   * ....
>>>   */
>>> public SecureRandom() {
>>> 
>>> What does "the default random number algorithm" mean?
>>> 
>>> I suggest we invent some new concepts in a CSR first.
>>> 
>>> Or, if we simply want to keep the expected behavior, I feel a little uncomfortable to make the "DEFAULT" alias visible to the public. Can we make all these logic internal? Maybe like this?
>>> 
>>> +            if (p.getName().equals("SUN")) {
>>> +                return SunEntries.DEFAULT; // and assign DEFAULT somewhere in SunEntries
>>> +            }
>>> 
>>> 
>>> --Max
>>> 
>>>> On Aug 7, 2019, at 8:59 AM, Valerie Peng <valerie.peng at oracle.com> wrote:
>>>> 
>>>> 
>>>> Anyone can help review this fix? SUN provider supports multiple impls of SecureRandom and rely on the ordering of the set returned by Provider.getServices() to choose the most preferred RNG algo for new SecureRandom() calls. Instead of maintaining the ordering, I think it's faster and more robust to use an alias "DEFAULT" to indicate the most preferred RNG algo for SUN provider.
>>>> 
>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8228613
>>>> 
>>>> Webrev: http://cr.openjdk.java.net/~valeriep/8228613/webrev.00/
>>>> 
>>>> Thanks,
>>>> Valerie