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

[Valerie Peng]

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?

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