Thanks for the review~ For this fix, let's just address the regression.
I will file a separate RFE to track how providers can indicate their
preferred secure random algorithm for new SecureRandom() calls.
Valerie
On 8/12/2019 7:20 PM, Weijun Wang wrote:
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.p...@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.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
