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?
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.p...@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
